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ABSTRACT 


The  discipline  of  software  engineering  is  on  the  move  from  an  "art"  to  an 
engineering  science  based  on  mathematical  rules.  Along  this  way  methods  of  rapid 
prototyping  and  tools  for  automatic  program  generation  are  being  developed  to  aid  the 
process  of  software  development.  This  thesis  takes  a  real  life  example  of  an  Inertial 
Navigation  System  and  develops  it  according  to  the  automation  principle  (nr  computer 
aided  software  development.  The  techniques  of  rapid  software  prototyping  are  also 
applied  to  the  same  problem.  The  software  prototype  of  the  Inertial  Navigation  System 
can  further  be  run  through  The  Computer  Aided  Prototyping  System  (CAPS)  to 
mechanically  generate  Ada  software.  All  implementation  worfc  is  done  in  Ada  as  required 
by  DcD  for  all  embedded  weapon  systems.  The  two  approaches  will  be  integrated  for 
analysis. 
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I.  INTRODUCTION 


A.  THE  SOFTWARE  CRISIS 

What  is  the  software  crisis?  To  explain  this  a  look  at  the  development  of  computers 
will  be  helpful.  The  early  machines  had  very  little  memory  capacity,  therefore  the 
programs  which  could  run  on  these  machines  had  to  be  restricted  in  their  need  for 
memory  as  well  (the  technique  of  overlays  had  not  evolved  then).  Since  programs  were 
small  it  was  very  easy  for  a  single  person  to  comprehend  a  program  in  its  entirety.  In 
those  days  programming  was  more  of  an  art  than  a  science.  The  major  portion  of  the 
cost  of  a  computer  system  was  associated  with  hardware.  Computers  have  come  a 
long  way  since  then.  Memory  capacity  has  increased  to  a  level  that  was  considered 
impossible  only  a  few  years  ago.  Presently  hardware  technology  advances  at  a  speed 
of  improving  the  memory  capacity  and  speed  by  a  factor  of  two  about  every  two  years. 

Unfortunately  the  software  side  of  computer  systems  has  not  been  able  to  keep  up 
with  hardware  development.  More  and  more  problems  are  considered  to  be  suitable 
for  automation  and  computer  application,  the  problem  domain  expanded.  Soon  no  one 
person  was  able  to  comprehend  a  software  system  as  a  single  person,  but  the 
techniques  used  were  the  same  as  in  the  beginning.  This  led  to  the  software  crisis, 
the  symptoms  are  described  by  Booch  [Ref.  1  :p.  8]  as: 

•  Responsiveness.  Computer-based  systems  often  do  not  meet  user  needs. 

•  Reliability.  Software  often  fails. 

•  Cost.  Software  costs  are  seldom  predictable  and  are  often  perceived  as  excessive. 

•  Modifiability.  Software  maintenance  is  complex,  costly,  and  error  prone. 

•  Timeliness.  Software  is  often  late  and  frequently  delivered  with  less-than-promised 
capability. 
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•  Transponp.jility.  Software  from  one  system  is  seldom  used  in  an  other,  even  when 
simi'ar  .unctions  are  required. 

•  Efficiency.  Software  development  efforts  do  not  make  optimal  use  of  the  resources 
involved  (processing  time  and  memory  space). 

Having  stated  the  symptoms  of  the  crisis,  the  next  question  must  be  about  the 
causes,  which  are  summarized  by  Devlin  [Ref.  2:p.  2]  as: 

•  Failure  of  organizations  to  understand  the  life-cycle  implications  of  software 
development. 

•  A  shortage  of  personnel  trained  in  software  engineering. 

•  The  von  Neumann  architectures  of  most  of  our  machines  discourage  the  use  of 
modern  programming  practices. 

•  The  tendency  of  organizations  to  become  entrenched  in  the  use  of  archaic 
programming  languages  and  practices. 

This  research  explores  two  efforts  which  have  been  undertaken  over  the  last  years 
to  solve  the  above  stated  problems.  The  following  two  sections  will  give  a  brief 
overview. 

B.  RAPID  PROTOTYPING 

One  effort  to  increase  software  development  productivity  is  rapid  software 
prototyping  It  is  especially  worthwhile  in  the  development  of  hard  real  time  systems 
In  traditional  Software  production,  a  system  has  to  be  fully  implemented  to  confirm  that 
the  final  product  meets  the  requirements.  The  idea  behind  rapid  prototyping  is  to  create 
a  prototype  of  the  proposed  system  to  verify  that  the  real  time  behavior  demanded  by 
the  customer  is  feasible  under  the  imposed  constraints.  This  can  save  tremendous 
amounts  of  resources  in  terms  of  money  and  work,  because  the  feasibility  of  the 
system  is  verified  before  the  actual  design  and  implementation  of  the  system  is 
undertaken.  Design  errors  are  magnitudes  cheaper  to  correct  at  this  level  compared  to 
redesigning  and  recoding  of  a  finished  product  which  doesn't  meet  the  customer 
requirements. 
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One  such  system  for  rapid  prototyping,  called  CAPS  (Computer  Aided  Prototyping 
System)  which  is  based  on  PSDL  (Prototype  System  Description  Language)  is  presently 
under  development  in  a  research  project  at  NPS.  Background  information  on  the  CAPS 
and  a  more  in  depth  reference  to  PSDL  can  be  found  in  [Ref.  3,  4,  5,  6,  7,  8].  In  this 
thesis  features  of  PSDL  and  CAPS  concepts  will  be  explained  only  the  extend  that  is 
necessary  for  understanding  and  these  explanations  will  be  given  as  the  need  arises. 

C.  FORMAL  SOFTWARE  ENGINEERING 

Another  approach,  which  consideres  the  complete  software  lifecycle  anmd  not  just 
the  prototyping  aspect  of  software  development  was  developed  by  Berzins  and  is 
descnbed  in  [Ref.  9],  The  following  is  a  short  extract  to  summarize  the  key  concepts 
of  his  approach. 

DEFINITION: 

Software  Engineering  is  the  application  of  science  and  mathematics  to  the  problem 
of  making  computers  useful  to  people  by  means  of  software. [Ref.  9:p.  1-1] 

Software  development  can  be  viewed  as  a  five  stage  process.  The  concept  and 
the  relations  between  the  different  stages  can  be  seen  in  [Figure  1  :p.  3] 
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The  downarrows  show  the  normal  flow  of  execution,  the  uparrows  represent  details 
gained  at  a  later  stage,  which  require  the  repetition  of  an  earlier  step.  The  long  arrow 
labeled  "  Evolution"  demonstrates  that  every  software  product  Is  subject  to  change  due 
to  altered  operating  conditions  or  user  needs. 

Each  of  these  five  steps  is  associated  with  certain  goals,  which  are  described  in 
[Ref  9:p.  12)  as: 

•  REQUIREMENTS  ANALYSIS:  Is  the  process  of  determining  and  documenting 

the  user  needs  and  constraints. 

•  FUNCTIONAL  SPECIFICATION:  Is  the  process  of  proposing  and  formalizing  a 

proposed  system  interface  for  meeting  the 

customer  needs. 

•  ARCHITECTURAL  DESIGN:  Is  the  process  of  decomposing  the  system  into 

modules  and  defining  internal  interfaces. 

•  IMPLEMENTATION:  Is  the  process  of  producing  a  program  for  each 

module. 

•  EVOLUTION:  lr  the  process  of  adapting  the  system  to  the 

changing  needs  of  the  customer. 
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II.  THE  PROTOTYPE  APPROACH 


A.  ABOUT  CAPS 

CAPS  can  be  characterized  as  a  composition  of  separate  tools  which  provide  the 
means  to  create  a  prototype  of  a  software  system  in  a  fraction  of  the  time  the  actual 
development  would  take.  It  is  not  meant  to  replace  a  good  software  development 
environment,  but  to  aid  it  and  make  it  even  better.  The  prototyping  system  as  mentioned 
in  Chapter  I,  has  not  yet  been  completely  implemented;  therefore  a  summary  of  the 
capabilities  of  the  completed  system  will  be  given.  A  description  of  the  currently 
operational  parts  that  were  used  for  this  thesis  as  well  as  the  development  state  of  the 
other  parts  will  follow.  The  system  incorporates  these  tools: 

•  User  Interface 

•  Graphic  Editor 

•  Syntax  Directed  Editor 

•  Language  Translator 

•  Debugger 

•  Static  Scheduler 

•  Dynamic  Scheduler 

•  Software  Base  Management  System 

•  Design  Database 

The  user  interface  ties  all  the  tools  together.  It  takes  care  of  the  proper  filename 
conventions  and  file  formats  to  be  passed  between  the  tools.  For  the  development  of 
a  new  prototype,  the  designer  would  start  with  the  graphic  editor  tool. 


5 


The  graphic  editor  supports  a  graphical  representation  of  the  dataflow  model 
underlying  the  PSDL  language.  Building  blocks  of  the  graphic  language  are  nodes  and 
arcs.  Nodes  represent  functions  or  state  machines,  collectively  called  operators.  Arcs 
represent  dataflows  among  others,  external  inputs  or  outputs. 

Once  in  the  graphic  editor,  the  mouse  becomes  the  primary  input  device  for  control 
over  the  editor,  whereas  text  input  is  entered  via  the  keyboard  into  designated  windows. 
The  following  operations  are  available  to  the  user: 

•  for  file  management: 

•  LOAD  EXISTING  -  to  retrieve  a  previously  created  file  for  modification. 

•  STORE  -  to  store  the  current  graphical  representation  of  a  prototype. 

•  QUIT  -  to  return  to  the  user  interface. 

•  for  editing: 

•  DRAW  OPERATOR  -  to  draw  an  operator.  Each  operator  must  have  a  unique 

identifier  and  a  time  constraint  which  is  the  maximum 
execution  time  associated  with  the  operator. 

•  DRAW  DATA  FLOW-  to  draw  a  data  flow  between  two  operators,  it  also  must 

have  a  unique  identifier  and,  since  the  direction  of  a  data 
flow  is  important,  it  must  be  taken  care  of  during  the 
drawing  process.  The  data  flow  has  to  start  at  its  originating 
operator  and  end  at  its  destination  operator. 

•  DRAW  SELF  LOOP  -  to  draw  a  self  loop,  which  is  the  graphic  representation  of 

a  state  variable,  a  PSDL  construct  necessary  to  describe 
a  state  machine. 

•  DRAW  INPUT  -  to  draw  an  external  input  into  the  system.  This  is  also  a 

data  flow  with  the  difference  that  it  doesn't  flow  from  one 
operator  to  another,  but  from  an  external  source  e.g.  user, 
other  software  or  hardware  system. 

•  DRAW  OUTPUT  -  to  draw  an  external  output,  similar  to  drawing  an  input. 

except  for  the  direction. 

A  system  screen  dump  taken  during  the  creation  of  operator  INS  is  shown  in 
[Figure  2:p.  7],  After  leaving  the  graphic  editor  certain  files  are  created,  whose  contents 
will  be  described  during  the  actual  development  process  later  on. 
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Output  from  the  graphic  editor  in  textual  form  is  feed  into  the  syntax  directed  editor, 
whose  main  purpose  is  to  guarantee  the  completion  of  a  syntactically  correct  PSDL 
program.  It  assists  the  user  in  adding  information  into  the  prototype  which  is  not  easily 
representable  in  graphic  form  e.g.  periodical  behavior  of  an  operator,  type 
declarations  for  data  flows  of  all  three  kinds  and  triggering  conditions.  The  importance 
of  syntactically  correct  PSDL  programs  becomes  obvious  in  the  employment  of  the  next 
tool,  the  language  translator,  which  relies  on  this  property  to  translate  a  PSDL  program 
into  executable  Ada  code. 

The  static  scheduler  takes  the  output  from  the  language  translator  and  creates  a 
time  schedule  for  the  execution  of  all  time-critical  operators  and  organizes  it  so  that  all 
timing  constraints  will  be  met  during  execution  if  possible.  All  non  time-critical  operators 
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are  handled  by  the  dynamic  scheduler.  It  checks  the  static  schedule  for  any  unused 
time  slots  and  schedules  non  time-critical  operators  for  execution  during 
those  times.  The  execution  of  non  time-critical  operators  may  be  suspended  before 
completion,  when  the  static  scheduler  needs  the  resources  for  a  time-critical  operator. 

Whenever  there  is  a  conflict  during  the  creation  of  the  schedules  or  the  execution 
of  the  prototype,  the  debugger  is  invoked,  to  give  the  user  a  chance  to  solve  the  conflict 
dynamically  on  line,  instead  of  breaking  off  execution  and  thereby  forcing  the  repetition 
of  the  whole  scheduling  process  from  the  beginning. 

Two  databases  complete  the  system.  The  software  base  contains  reusable  Ada 
components,  which  are  searched  for  using  the  PSDL  specification  of  an  operator,  the 
design  data  base  keeps  track  of  the  prototype  currently  under  construction,  it  maintains 
this  information  by  storing  PSDL  specifications. 

The  user  interface  and  graphic  editor  are  completely  implemented  and  were  used 
for  this  thesis.  The  language  translator  is  implemented  as  well,  but  does  not  yet  include 
all  the  constructs  used  in  this  project  such  as  composite  data  types,  therefore  it  was  not 
used.  For  ail  the  other  components  designs  exist,  some  are  partially  implemented,  but 
not  operational. 

B.  THE  INS  PROTOTYPE  DEVELOPMENT  IN  PSDL 

The  first  tool  to  be  used  in  the  prototype  development  is  the  graphic  editor.  It  is 
implemented  on  a  SUN  workstation  and  makes  extensive  use  of  its  windowing  and 
graphics  capabilities.  The  editor  is  invoked  from  the  main  menu  of  the  user  interface 
with  option  "construct"  [Ref.  3].  This  in  turn  invokes  the  'GE'  script.  At  the  top  level 
design  of  INS  only  one  operator  exists  with  all  inputs  and  outputs  intended  for  the 
complete  system.  No  timing  constraints  were  placed  on  operator  INS.  The  inputs  and 
outputs  are  data  streams  of  type  data  flow.  Streams  behave  like  FIFO  queues  (first-in- 
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first-out)  with  a  fixed  length  of  one  element,  thereby  implying,  that  a  new  value  can  only 
be  added  to  the  queue,  after  the  old  value  has  been  read.  For  further  explanations  see 
[Ref.  6:p.  9].  After  all  the  entities  have  been  entered  into  the  graphic  editor,  the  picture 
is  saved  in  the  file  SYS.G.  The  GE  script  partially  produces  the  syntactically  correct 
PSDL  specification  for  operator  INS,  where  only  the  data  types  for  the  input  and  output 
data  have  to  be  specified,  which  would  normally  be  done  in  the  syntax  directed  editor. 
Since  it  is  not  operational  at  this  time,  the  editing  has  to  be  done  manually  in  a 
standard  word  processor. 

The  following  represents  the  specification,  which  is  partially  created  by  GE  and 
completed  manually  by  adding  the  datatypes: 

OPERATOR  INS 
SPECIFICATION 


INPUT  Present  Position 

POSITION 

Course 

FLOAT; 

Speed 

INTEGER; 

WP  1 

POSITION 

WP  2 

POSITION 

WP_3 

POSITION 

WP  number 

INTEGER; 

New  time 

TIME; 

New_choice 

INTEGER; 

OUTPUT  Present  Position 

POSITION; 

Course 

FLOAT; 

Speed 

INTEGER; 

WP  1 

POSITION; 

WP  2 

POSITION; 

WPJ3 

POSITION; 

WP  number 

INTEGER; 

Bearing 

FLOAT; 

Distance 

FLOAT; 

END 

Since  the  design  database  does  not  contain  an  implementation  for  operator  INS,  it 
needs  to  be  decomposed.  The  graphic  representation  is  provided  in  [Figure  3:p.  10]. 
New  constructs  used  in  the  decomposition  are  state  variables,  which  are  represented 
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Figure  3:  Decomposition  of  Operator  INS 

as  self  loops  and  data  streams  between  operators,  but  unlike  the  data  streams  into  and 
out  of  operator  INS  these  are  sampled  data  streams,  which  means  that  the  data  are 
buffered.  A  new  value  can  be  written  to  the  buffer  regardless  of  whether  the  old  value 
has  been  read  or  not.  The  buffer  can  be  read  as  often  as  needed,  always  providing  the 
most  recent  data  value. 

As  soon  as  a  value  has  been  placed  into  it  for  the  first  time,  a  read  operation  does 
not  destroy  the  old  data  value,  whereas  a  write  operation  will  replace  the  old  value  with 
the  most  recent  one.  For  further  explanations  see  [Ref.6:p.  9].  In  this  example  operators 
CHECK_KEYBOARD,  COMPUTE_POSITION  AND  COMPUTE_BEARING_DISTANCE 
are  atomic  and  need  no  further  decomposition.  Atomic  operators  are  those  which  are 
already  in  the  design  database  or  can  be  easily  implemented  in  Ada. 

CHECK_KEYBOARD  as  its  name  suggests  checks  the  keyboard  for  an  interrupt, 
which  in  turn  directs  the  flow  of  control  for  the  lower  levels  of  the  system  depending  on 


user  input.  If  no  new  interrupt  is  sensed,  the  control  is  directed  according  to  the  last 
interrupt.  This  scheme  turns  the  system  in  its  entirety  into  a  state  machine.  Control  of 
the  lower  levels  is  executed  via  the  data  streams  OLD_CHOICE  or  NEW_CHO!CE. 

COMPUTE_POSITION  is  an  independent  process  which  updates  the  present  position 
of  the  aircraft  using  the  velocity  values  received  by  the  system,  the  last  valid  present 
position,  called  OLD_POSITION,  or  a  new  position  entered  by  the  user.  It  produces  a 
new  present  position,  called  MOST_RECENT_POSITION.  The  reason  for  using  three 
different  names  for  the  same  entity,  a  present  position,  lies  in  the  naming  conventions 
used  in  the  graphic  editor  and  PSDL  itself.  If  the  same  name  is. used  for  several  data 
streams  (overloading)  the  system  treats  all  those  streams  as  being  the  same  which  is 
not  really  the  case. 

COMPUTEJ3EARING_DISTANCE  is  another  independent  process  working  on  the 
MOST  RECENT  POSITION,  a  WP_NUMBER  which  represents  a  user  choice  and  the 
respective  waypoint  data  contained  in  WP_1,  WP_2  or  WP_3  respectively.  The  outputs 
BEARING  and  DISTANCE  are  stored  in  their  appropriate  buffers. 

Operator  DISPLAY_HANDIER  is  composite.  [Figure  3:p  11]  gives  the  graphic 
representation.  All  operators  at  this  level  are  atomic;  they  comprise  input  and  output  for 
the  system.  The  left  column  contains  the  operators  responsible  for  input.  In  the  middle 
column  the  data  buffers  are  grouped  together.  Inputs  to  these  buffers  are  all  of  type 
sampled  data  stream.  Operators  for  system  output  are  in  the  right  column. 

A  word  of  explanation  about  the  data  buffers  used  is  in  order  here.  The  fact  that 
the  above  mentioned  data  streams  are  considered  to  be  sampled  data  stream  implies 
that  they  are  inherently  buffered,  therefore  no  buffers  as  depicted  in  [Figure  3:p.  10] 
need  to  be  explicitly  mentioned,  however  they  are  Included  here  for  a  better 
understanding  of  the  system  layout.  In  the  strict  sense  of  PSDL  the  middle  row  in  the 
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figure  could  be  eliminated  without  changing  the  meaning  or  behavior  of  the  overall 
system. 


In  addition  to  creating  the  PSDL  specification  the  file  PSDL.LINKS  is  created, 
which  contains  the  textual  representation  of  the  operators  in  the  form  of  link  statements 
connecting  the  different  operators.  At  the  end  is  a  list  of  all  internal  data  streams,  its 
contents  for  the  decomposition  of  OPERATOR  INS  is  shown  below  and  on  the  next 
page. 
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OPERATOR  INS: 


Old_choice.Check_keyboard  -->  Check_keyboard 

Old_choice.Check_key board  -->  Display_handler 

New_choice.Check_keyboard  ~>  Display_handler 

Bearing. Compute_bearing_distance  -->  Disptay_handler 

Distance. Compute_bearing_di  stance  -->  Display_hand(er 

Speed. Display_handler  -->  EXTERNAL 

Speed. Dispiay_handler  -->  Compute_posltion 

Course.  Display _handler  -->  EXTERNAL 

Course.  Display_handfer  ~>  Compute jx)sltion 

Old_Position.Display_handler  -->  Compute_position 

Bearing. Display_handler  -->  EXTERNAL 

Distance. Display _handler  -->  EXTERNAL 

WP_1  .Display_handler  ->  EXTERNAL 

WP  2.Display_handler  -->  EXTERNAL 

WP_3.Display_handler  ->  EXTERNAL 

WP_number.Display_handler  -->  Compute_bearing_distance 

WP_3.Display_handler  -->  Compute_bearing_distance 

WP_2. Display  handler  ->  Compute_bearing_di stance 

WP_1  .Display_handler  -->  Compute_bearing_distance 

WP_number.Display_handler  -->  EXTERNAL 

Most_recent _position.Display_handler  -->  EXTERNAL 

New_choice. EXTERNAL  Check_key board 

Old_time.Compute_position  -->  Compute__position 

Most_recent_position. Compute ^position  -->  Display_handler 

Mostrecent _position.Compute_position  -->  Compute_bearing  distance 

WP  number. EXTERNAL  -->  Display__handler 

New  time. EXTERNAL  -->  Compute_position 

WP_1. EXTERNAL  -->  Display_handler 

WP_2. EXTERNAL  ->  Display_handler 

WP_3. EXTERNAL  -->  Display_handler 

Present  Position. EXTERNAL  -->  Display_handler 

Course. EXTERNAL  -->  Display_handler 

Speed. EXTERNAL  -->  Display _handler 

DATA  STREAM 


Bearing 

FLOAT; 

Distance 

FLOAT; 

Speed 

INTEGER; 

Course 

FLOAT; 

WP  number 

INTEGER; 

WP  3 

POSITION; 

WP  2 

POSITION; 

WP_1 

POSITION; 

Old_Position 

POSITION; 

Old_choice 

INTEGER; 

New_choice 

INTEGER; 

Most_recent_position 

POSITION; 
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The  three  lines 


[1]  Old_choice.Check_keyboard  ~>  Check_key board 

[2]  Course. Display_handler  -->  Compute _position 

[3]  Present_Position. EXTERNAL  -->  Display _handler 

are  typical  for  the  possible  data  streams.  [1]  represents  a  state  variable  and  can  be 
read  as:  there  is  a  data  stream  called  Old_choice  originating  at  operator 
Check_keyboard  and  also  ending  at  that  operator.  [2]  is  a  standard  data  stream 
between  two  operators.  [3]  shows  an  external  input  to  the  system,  a  similar  format  is 
used  for  outputs. 

The  last  items  needed  to  completely  specify  operator  INS.  are  potential  control 

constraints  for  its  subcomponents,  which  have  been  defined  as: 

CONTROL  CONSTRAINTS 

OPERATOR  DISPLAY JHANDLER 
PERIOD  Is 

OPERATOR  COMPUTE_BEARING_DISTANCE 
PERIOD  Is 

OPERATOR  COMPUTE_POSITION 
PERIOD  Is 

These  constraints  do  not  appear  in  graphic  representation,  since  it  only  shows 
maximum  execution  times.  For  clarification  of  an  operator  the  design  language  includes 
a  description  construct. 

DESCRIPTION 

{This  is  the  root  operator.  It  is  composite  and  consists  of  the  composite  operator 
DISPLAY_HANDLER  and  the  atomic  operators  CHECK_KEYBOARD. 
COMPUTE_BEARING_DISTANCE  and  COMPUTE_POS!TION} 

END 

Since  the  rest  of  the  development  is  a  repetition  of  the  steps  described  so  far,  that 
work  is  not  presented  here.  A  complete  PSDL  specification  for  the  system  can  be  found 
in  Appendix  E.  Operator  COMPUTE_POSlT!ON  is  used  on  the  next  page  to  clarify  a 
certain  aspect  which  might  confuse  the  reader. 
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OPERATOR  COMPUTE_POSITION 
SPECIFICATION 


INPUT  Speed 
Course 
Old_Position 
New  time 


INTEGER; 

FLOAT; 

POSITION; 

TIME; 


OUTPUT  Most_recent_position:  POSITION; 


STATE  Oldjime  :  TIME; 


END 


Part  of  a  complete  PSDL  implementation  of  an  operator  is  the  TRIGGER 
CONDITION,  which  can  take  on  the  values  BY  ALL  or  BY  SOME  [Ref.  6:p.  26],  The 
fact  that  no  TRIGGER  CONDITION  is  used  indicates  that  the  default  value  TRIGGERED 
BY  ALL  is  used.  In  the  case  of  operator  COMPUTE_POSITION  all  four  inputs  SPEED, 
COURSE.  OLD_POSITION  and  NEW_TIME  have  to  be  present  to  fire  the  operator. 
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III.  THE  FORMAL  SOFTWARE  ENGINEERING  APPROACH 

A.  PREFACE 

The  system  development  will  follow  the  steps  as  outlined  in  [Ref.  9]  which  was 
summarized  in  the  introduction  [see  p.  4].  It  is  assumed,  that  the  reader  has  familiarized 
himself  with  the  sequence  and  purpose  of  each  step.  This  is  a  case  study  aimed  at 
exploring  methods  for  software  development  and  not  at  creating  a  system  of  production 
quality  for  operational  use,  therefore  certain  aspects  of  the  system  such  as  the  concept 
of  wind'  will  be  left  out  of  consideration. 

B.  THE  INITIAL  PROBLEM  STATEMENT 

The  proposed  software  system  Is  an  Inertial  Navigation  System  (INS)  to  be 
used  In  aircraft.  It  Interacts  with  the  flight  directory  system.  The  system  must 
be  capable  of  deriving  the  present  position  of  the  aircraft  and  provide 
Information  about  the  flight  parameters  as  well  as  destination  data  for  selected 
destinations.  Additional  data  needed  for  aircraft  steering  must  be  available. 

C.  REQUIREMENTS  ANALYSIS 

1.  The  System's  Environment  Model 

To  create  a  vocabulary  to  which  all  persons  involved  in  the  development  process 
can  refer  and  agree  a  model  of  the  system's  environment  is  built.  For  this  example  it 
is  the  following: 

•  The  INS  will  be  a  software  system. 

•  It  will  interact  with  the  flight  directory  system  (FDS),  the  user  and  the  velocity  unit 
(VU). 

•  The  FDS  is  a  device  used  to  steer  the  aircraft  in  an  automatic  mode. 

•  The  VU  is  the  part  of  the  overall  system  where  the  aircraft  acceleration  in  all  three 
dimensions  is  measured  and  converted  into  velocities. 

•  Automatic  mode  describes  the  fact  that  the  aircraft  is  steered  by  the  computer  and 
not  by  the  pilot. 
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•  The  present  position  is  the  aircraft's  position  relative  to  the  earth’s  surface,  it  is 
e/.pressed  in  terms  of  latitude  and  longitude. 

•  Flight  parameters  are  measures  of  the  aircraft's  behavior  with  respect  to  movement 
in  space  consisting  of  the  components  course,  speed  and  attitude. 

•  A  destination  is  a  point  in  space  expressed  in  the  same  terms  as  present  position. 

•  Destination  data  are  measures  of  the  relative  position  of  the  aircraft  to  the 
destination. 

•  Data  for  steering  the  aircraft  are  those  that  are  needed  by  the  flight  directory  system 
to  steer  the  aircraft  to  the  selected  destination. 

2.  Goals  and  Functions  of  the  System 

To  derive  the  high  level  goats  the  initial  problem  statement  is  used.  For  the 
proposed  system  they  are: 

G1:  The  purpose  of  the  INS  is  to  help  the  aircrew  to  navigate  their  aircraft. 

G 1 . 1 :  The  system  must  provide  information  about  the  state  of  the  aircraft. 

G1.2:  The  system  must  calculate  destination  data  for  destination  positions. 

G1.3:  The  system  must  provide  data  necessary  to  steer  the  aircraft. 

G1.4:  The  system  is  supposed  to  be  highly  concurrent  and  prepared  for  future 
extensions. 

3.  Constraints 

With  the  development  of  every  system  certain  constraints  like  a  fixed  budget  or 
delivery  dates  are  associated;  which  are  usually  implied  by  the  customer.  For  our 
example  they  are  aimed  at  making  this  project  feasible  and  suitable  for  the  academic 
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environment. 


Implementation  Constraints 

Cl:  The  system  has  to  be  implemented  in  Ada 

C2:  The  implementation  should  aim  at  a  high  level  of  concurrency. 

C3:  The  compilers  available  are 

•  VERDIX  on  a  SUN  workstation 

•  Meridian  AdaVantage  on  a  IBM  XT  compatible  PC 

•  INTEGRADA  on  a  IBM  XT  compatible  PC 
Performance  Constraints 

C4:The  positional  data  and  destination  data  have  to  be  updated  every  second. 

C5:The  system  must  allow  for  future  extensions. 

Resource  Constraints 

C6:The  system  must  be  developed  within  three  month  by  one  person. 

4.  Refined  Goals 

Continuing  in  the  development  process,  the  high  level  goals  derived  earlier, 
have  to  be  refined.  This  is  done  by  identifying  the  concepts  in  the  high  level  goals 
which  need  to  be  explained  further.  The  goals  are  repeated  here  for  easier  reference. 

G1.1:  The  system  must  provide  Information  about  the  state  of  the  aircraft. 

The  concept  of  ’state  of  the  aircraft’  needs  to  be  refined;  it  consists  of  information 
about  the  aircraft's  position  and  its  flight  parameters.  These  concepts  have  been 
explained  in  the  environment  model;  therefore  the  refined  goals  for  G1.1  are: 

G1.1.1:  The  system  must  provide  the  aircraft  present  position. 

Gl.1.2:  The  system  must  provide  the  aircraft  course. 

G1.1.3:  The  system  must  provide  the  aircraft  speed. 

G1.1.4:  The  system  must  provide  the  aircraft  altitude. 
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Another  level  of  refinement  is  needed  to  define  the  units  of  the  above  introduced 
entities  and  their  meanings. 

G1. 1.1.1:  The  position  consists  of  latitude  and  longitude,  both  measured  in  degrees(°), 
Minutes(')  and  Seconds(").  Latitude  can  take  on  values  from  90°  south  to  90° 
north.  The  range  for  longitude  extends  from  1 80°  west  to  1 80°  east. 

G1.1  2.1:  Course  is  measured  in  degreesf),  oriented  to  true  north  which  equals  a 
course  of  0°. 

G1. 1.3.1:  Speed  is  measured  in  knots(KTS)  and  can  range  from  0  to  499KTS. 

G1. 1.4.1:  Altitude  is  measured  in  feet(ft)  and  ranges  from  0  to  50000ft. 

G1.2:  The  system  must  calculate  destination  data  for  destination  positions 

'Destination  data'  as  mentioned  in  the  environment  model  determine  the  relative 
position  of  the  aircraft  to  a  destination  position.  This  relation  is  expressed  in  terms  of 
true  bearing  and  distance. 

G1.2.1:  The  system  must  calculate  the  true  bearing  from  the  aircraft  to  a  destination 

position. 

Gl.2.2:  The  system  must  calculate  the  distance  from  the  aircraft  to  a  destination 

position. 

G1.3:  The  system  must  provide  data  necessary  to  steer  the  aircraft. 

In  G1.3  the  concept  of  'data  necessary  to  steer  the  aircraft’  needs  refinement. 
The  environment  model  mentions  that  the  aircraft  can  be  flown  in  automatic  mode. 
Consequently  the  steering  data  must  be  those  needed  to  employ  that  automatic  mode. 
In  order  for  the  aircraft  to  fly  to  a  destination  position  ft  needs  a  direction  to  fly  in,  which 
e.g.  can  be  provided  as  a  bearing  relative  to  the  present  course.  This  relative  bearing 
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is  the  difference  between  the  present  aircraft  course  and  the  true  bearing  of  the  aircraft 
to  the  destination  position.  Refinement  of  G1.3  results  in: 

G1.3.1:  The  system  must  provide  true  bearing  to  a  destination  position. 

G  1.3.2:  The  system  must  provide  relative  bearing  to  a  destination  position. 

After  defining  ail  these  goals  the  question  arises  how  they  can  be  met;  where 
does  all  the  information  to  satisfy  the  goals  come  from?  In  this  case  all  the  necessary 
data  will  be  computed  inside  the  INS  and  the  data  these  computations  will  be  based 
on  will  enter  the  system  via  its  interfaces  to  the  user  and  the  velocity  unit,  which  will 
be  defined  in  the  functional  specification. 

G1.4:  The  system  Is  supposed  to  be  highly  concurrent  and  prepared  for  future 
extensions. 

The  goals  in  G1.4  cannot  be  refined  here,  they  will  be  considered  in  the 
architectural  design  stage  and  in  the  implementation. 


D.  FUNCTIONAL  SPECIFICATION 

Berzins  provides  procedures  and  guidelines  for  the  conduct  of  a  functional 
specification  in  [Ref.9:p.  3-16].  Each  step  is  quoted  here  to  enable  the  reader  to  follow 
the  development  process  more  easily. 

STEP  1 

"Identity  the  major  subsystems  of  the  proposed  software  and  the  user  classes  and 
external  systems  with  which  the  proposed  software  system  will  interact." 

Using  the  environment  model  created  earlier,  the  following  entities  are  identified: 

•  There  will  be  one  INERTIAL_NAVIGATION_SYSTEM  software  system. 

•  The  system  will  interact  with  three  external  systems,  USER, 
FLIGHT_DIRECTORY_SYSTEM  and  VELOCITYJJNIT,  the  latter  two  being  hardware 

devices. 

No  subsystems  are  identified  at  this  time. 
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STEP  2 


"Identify  all  external  interfaces  of  the  proposed  subsystems,  and  make  a  list  of  the 
messages  in  each  interface.  Make  sure  the  identified  messages  correspond  to  the 
goal  hierarchy,  and  go  over  the  lists  with  the  customer.  Create  a  SPEC  module  for 
each  external  system,  subsystem  and  interface.  Set  up  the  inheritance  links  between 
the  interfaces  and  the  proposed  subsystems." 

There  are  three  external  systems,  one  interface  for  each  one  is  needed.  They 
are  named  as:  userjnterface,  flight_dlrectory_system_interface  and 
velocity  _unitjnterface.  The  definitions  given  so  far  are  summarized  in  [Figure  5:p.  21] 
to  insure  the  proper  understanding  of  the  general  layout  of  the  proposed  system  before 
continuation. 


To  avoid  repetition  of  writing  and  reading,  the  lists  of  messages  pertaining  to 
each  interface  are  incorporated  into  the  corresponding  SPEC  constructs  right  away.  A 
’?'  in  a  specification  marks  an  entity  that  is  non  trivial  and  needs  further  refinement  in 
a  later  stage  of  the  specification  process.  The  resulting  specification  are  shown  on  the 
next  page: 
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MACHINE  inertiai_navigation_system 
INHERIT  userjnterface 
INHERIT  flight_directory_systemJnterface 
INHERIT  velocity _unitjnterf ace 

STATE 

INVARIANT  true 
INITIALLY  true 
END 


MACHINE  flight_directory_system 
STATE  ? 

INVARIANT  true 
INITIALLY  true 

-  The  flight_directory  system  is  a  hardware  system,  therefore  it. will  not  be  considered 
--  any  further  in  the  development  process. 

END 


MACHINE  velocity_unit 
STATE  ? 

INVARIANT  true 
INITIALLY  true 

--  The  velocity_unit  is  a  hardware  system,  therefore  it  will  not  be  considered  any 
--  further  in  the  development  process. 

END 


MACHINE  user 
STATE  ? 
INVARIANT  true 
INITIALLY  true 
END 


MACHINE  userjnterface 
STATE  ? 

INVARIANT  true 
INITIALLY  true 

MESSAGE  new _position 

--  Enables  the  user  to  enter  the  coordinates  for  a  new  present  position  into  the 

-  system. 

MESSAGE  define_waypoint 

--  Enables  the  user  to  enter  the  coordinates  for  a  destination  waypoint  into  the 

-  system. 
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MESSAGE  select_way point 

-  Enables  the  user  to  select  one  of  the  waypoints  as  a  destination  for  computing 
--  destination  data  from  there  on. 

MESSAGE  display _select 

-  Enables  the  user  to  select  a  data  item  for  display  on  the  screen. 

END 

MACHINE  flight_directory_system_interface 
STATE  ? 

INVARIANT  true 
INITIALLY  true 

M ESSAGE  relative_bearing_to_a_WP 

-  Requests  a  relative  bearing  inertial_navigation_system  to  a  selected  waypoint  for 
--  steering  the  aircraft. 

END 


MACHINE  velocity_unit_interface 
STATE  ? 

INVARIANT  true 
INITIALLY  true 

MESSAGE  newvelocities 
-  Provides  new  velocity  data  to  MACHINE  ins. 
END 


Since  this  is  an  example  aiming  at  exploring  the  principles  of  software 
engineering  and  not  actually  develop  a  complete  system,  the  further  development  and 
refinement  will  not  be  done  for  all  components  but  only  for  those,  which  give  good 
examples  for  what  is  supposed  to  be  done  in  each  step  or  are  suitable  to  introduce  new 
concepts.  For  step  three  the  MACHINE  userjnterface  has  been  chosen. 

STEP  3 


"For  each  interface,  write  down  a  skeleton  specification  for  all  of  the  messages. 
Choose  names  for  all  messages,  exceptions  and  message  components,  and  identify 
the  data  type  of  each  message  component.  Identify  any  new  abstract  data  types 
needed,  and  create  SPEC  modules  for  them.  When  all  of  the  components  have 
been  identified,  make  an  initial  estimate  of  how  much  effort  it  will  take  to  build  the 
system." 

Step  three  yields  the  following  result  for  MACHINE  userjnterface,  where  the 
comments  relate  to  the  corresponding  goal,  developed  in  the  requirements  analysis: 
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MACHINE  userjnterface 
STATE  ? 

INVARIANT  true 
INITIALLY  true 

MESSAGE  new_position  (p:  position)  --G1.1.1 

TRANSITION  ? 

MESSAGE  define_waypoint  (waypoint:  position,  wp_number:  waypoint_number_range) 
-  G1.2 
WHEN  ? 

TRANSITION  ? 

OTHERWISE  REPLY  invalid_waypoint_number 

MESSAGE  select_waypoint  (wp_number:  integer)  --G1.2 

TRANSITION  ? 

MESSAGE  display_select  (display_selection:  display_option)  --G1.1,  G1.2 

TRANSITION  ? 

TEMPORAL  update_display  WHERE  PERIOD  ? 

SEND  ? 

END 

A  TEMPORAL  clause  has  been  introduced  here  to  represent  the  time  dependant 
behavior  of  the  interface.  It  will  be  elaborated  later  on. 

No  abstract  data  types  are  identified  at  this  time,  since  no  other  operations  than 
input  and  output  are  performed  on  either  of  the  data  types  position,  real  and  integer. 
STEP  4 

"Invent  conceptual  models  for  each  machine  and  type.  Develop  the  invariants  and 
initial  conditions,  and  define  the  concepts  needed  to  specify  them.  Check  the 
consistency  of  the  interfaces,  and  make  any  adjustments  needed." 

Before  the  INVARIANT  and  INITIALLY  conditions  can  be  discussed,  it  is 

necessary  to  elaborate  the  STATE  of  the  interface.  It  is  to  contain  the  following  entities: 

•  Present  position 

•  Course 

•  Speed 

•  Altitude 
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•  Waypoints  1  to  3  (From  here  on  the  system  is  supposed  to  be  able  to 

handle  up  to  three  waypoints) 

•  Current_waypoint_number 

•  Display_se!ection 

Since  the  components  in  the  STATE  can  take  on  only  defined  values,  e.g. 
display _selection  can  take  on  only  those  values  enumerated  in  type  display_option,  and 
there  are  no  unallowed  interactions  between  the  components  in  the  state,  INVARIANT 
is  true  for  all  possible  STATES. 

All  components  in  STATE  are  initialized  before  the  user  takes  control  over  the 
program.  The  refined  specification  for  MACHINE  userjnterface: . 


MACHINE  userjnterface 
STATE  (  present_position 
course 
speed 
altitude 
waypoint_1 
waypoint_2 
waypoint_3 
current_wp_number 
display_selection 


position, 

bearing_range, 

speed_range, 

altitude_range, 

position, 

position, 

position, 

waypoint_number_range, 
display_option  ) 


INVARIANT  true 


INITIALLY 


present_position 

course 

speed 

altitude 

waypoint_1 

waypoint_2 

waypoint_3 

current_wp_number 

display_selection 


=  [latitude::0.0.longitude::0.0], 

=  0.0, 

=  0, 

=  0, 

=  [latitude::0.0,iongitude::0.0], 
=  [latitude::0.0,longitude::0.0], 
=  [latitude  ::0.0,iongitude::0.0], 
=  1, 

=  present_position_choice 


MESSAGE  new_position  (p:  position) 

TRANSITION  ?  -  update  coordinates  for  present_position 

MESSAGE  define_waypoint  (waypoint:  position,  wp_number:  waypoint_number_range) 
WHEN  ?  -  distinguish  between  waypoints 
TRANSITION  ?  --  update  coordinates  for  a  waypoint 
OTHERWISE  REPLY  EXCEPTION  invalid_waypoint_number 

MESSAGE  se!ect_waypoint  (wp_number:  integer) 

TRANSITION  ?  --  update  the  waypoint  selection 
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MESSAGE  display_select  (display _selection:  display_option) 
TRANSITION  ?  --  update  display  choice 

TEMPORAL  update_display  WHERE  PERIOD  ? 

SEND  ? 

CONCEPT  position:  type 
WHERE  ? 

CONCEPT  bearing_range:  type 
WHERE  ? 

CONCEPT  speed_range:  type 
WHERE  ? 

CONCEPT  altitude_range:  type 
WHERE  ? 

CONCEPT  waypoint_number_range:  type 
WHERE  ? 

CONCEPT  distance_range:  type 
WHERE  ? 

CONCEPT  display_option:  type 
WHERE  ? 

END 


STEP  5 

"Develop  the  WHEN,  WHERE  and  TRANSACTION  clauses  for  each  message  and 
identify  the  concepts  needed  to  specify  them.  Refine  the  invariants  as  needed. 
Determine  IMPORT,  EXPORT  relations  for  shared  concepts  and  create  definition 
skeletons  for  each  concept.  The  definition  skeletons  should  define  the  types  of 
inputs  and  outputs  for  each  concept,  and  should  have  an  informal  description  of  the 
concept." 

STEP  6 

"Write  formal  definitions  for  concepts,  identifying  any  necessary  lower  level  concepts, 
and  writing  definition  skeletons  for  them.  Continue  until  all  concepts  have  been 
defined  in  terms  of  built-in  or  available  components.  Check  the  internal  consistency 
of  the  entire  specification,  and  resolve  any  conflicts." 

Steps  five  and  six  are  combined.  All  the  WHERE  and  WHEN  clauses  that  were 

marked  by  a  '?'  in  the  previous  step  are  elaborated  here.  The  result  is  shown  on  the 


MESSAGE  new_position  (p:  position) 

TRANSITION  present _position  =  p 

MESSAGE  define_waypoint  (waypoint:  position,  wp_number:  waypoint_number_range) 
WHEN  current_wp_number  =1 
TRANSITION  waypoint_1  =  waypoint 
WHEN  current_wp_number  =  2 
TRANSITION  waypoint_2  =  waypoint 
WHEN  current_wp_number  =  3 
TRANSITION  waypoint_3  =  waypoint 

OTHERWISE  --  no  other  choice  possible  due  to  type  restriction  tor  wp_number 

MESSAGE  se!ect_waypoint  (wp_number:  Integer) 

TRANSITION  current_wp_number  =  wp_number 

MESSAGE  display_select  (display_$election:  display_option) 

TRANSITION  *display_selection  =  display_selection 

TEMPORAL  update_display  WHERE  PERIOD  =  (1  second) 

WHEN  display_selection  =  present _position_choice 
SEND  display(p:  position)  TO  user 
WHERE  p  =  present_position 
WHEN  display_election  =  course_choice 
SEND  display(c:bearing)  TO  user 
WHERE  c  =  course 

WHEN  display_selection  =  speed__choice 
SEND  display(s:integer)  TO  user 
WHERE  s  =  speed 

WHEN  display_selection  »  altitude_choice 
SEND  display(a:altitude_range)  TO  user 
WHERE  a  =  altitude 

WHEN  display_selection  =  waypoint_choice 
SEND  (w:  position)  TO  user 

WHERE  IF  current_waypoint_number  =  1  THEN  w  =  waypoint_1 

ELSE  IF  current_waypoint_number  =  2  THEN  w  =  waypoint_2 
ELSE  w  =  waypoint_3 
Fl 

WHEN  display_selection  =  true_bearing_to_a_wp_choice 
SEND  (t:  bearing  range)  TO  user 
WHERE  t  =  tnje_bearing(present_position,  waypoint::  position) 

WHEN  display_selection  =  distance_to_a_wp_cholce 
SEND  (d:  distance_range)  TO  user 
WHERE  d  =  distance(present__position,  waypoint::  position) 

OTHERWISE  --  no  other  choice  possible  due  to  type  restriction  for 
-  display _selection 

CONCEPT  position:  type 

WHERE  position  =  TUPLE{latitude::  lat_range,  longitude::  lon_range) 

--  The  meaning  of  type  position  is  explained  in  G1. 1.1.1. 
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CONCEPT  bearing_range:  type 

WHERE  subtype(bearing_range,  real)  &  ALL(b:  bearing_range::  0.0<=b<360.0) 

A  compass  rose  has  values  from  0.0  to  360.0  degrees 

CONCEPT  speed_range:  type 

WHERE  subtype(speed_range,  integer)  &  ALL(s:speed_range::  0<=s<500) 

--  Maximum  speed  allowed  is  500  kts 

CONCEPT  altitude_range:  type 

WHERE  subtype(altitude_range,  integer)  &  ALL(a:altitude_range::  0<=a<=50000) 

-  Maximum  altitude  allowed  is  50000  feet 

CONCEPT  waypoint_number_range:  type 
WHERE  subtype(waypoint_number_range,  integer)  & 
ALL(w:waypoint_number_range::  1  <=w<=3) 

-  Only  three  waypoints  are  allowed 

CONCEPT  distance_range:  type 

WHERE  subtype(distance_range,  real)  &  ALL(d:distance_range::  0.0<=d<=1 0800.0) 

-  10800  is  the  maximum  number  of  nautical  miles  between  two  points  on  the 

-  earth’s  surface  it  is  equal  to  half  its  circumference. 

CONCEPT  display_option:  type 

WHERE  display_option  =  enumeration  {  present_position_choice, 

course_choice, 

speed_choice, 

altitude_cholce, 

waypoint_choice, 

true_bearing_to_a_wp_choice, 

distance_to_a_wp_choice) 

-  The  display_option  is  a  way  for  the  user  to  control,  which  data  item  is  displayed 

-  on  the  screen. 

CONCEPT  distance(present_position  waypoint:  position) 

VALUE  (d:  distance_range) 

-  uses  a  formula  from  spherical  geometry  to  calculate  the  distance  between  two 

-  points  on  earth's  surface  and  expresses  it  in  terms  of  distance_range 

CONCEPT  bearing(present_position  waypoint:  position) 

VALUE  (b:  bearing_range) 

--  uses  a  formula  from  spherical  geometry  to  calculate  the  bearing  between  two 
--  points  on  earth’s  surface  and  expresses  it  in  terms  of  bearing_range 

CONCEPT  lat_range:  type 

WHERE  subtype{lat_range,  real)  &  ALL{1:  lat_range::  -90.0<=l<=90.0) 

CONCEPT  lon_range:  type 

WHERE  subtype(lon_range,  real)  &  ALL(I:  lon__range::  -180.0<=l<=180.0) 

END 
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The  above  is  the  complete  abstract  functional  specification  for  MACHINE 
user  interface  and  marks  the  end  of  the  mechanical  development,  since  the  remainder 
would  be  a  repetition  of  the  used  methods  of  refinement.  As  a  first  result  of  this  work 
it  shall  be  mentioned  here,  that  this  kind  of  process  is  not  suitable  for  a  manual 
approach.  It  will  only  be  feasible  for  large  software  system  after  automated  tools  have 
been  developed,  which  aid  the  designer/analyst  in  the  process,  e.g.  a  syntax  checker 
is  already  available  and  was  used  to  verify  the  syntactical  correctness  of  the 
specification;  a  typechecker  and  a  syntax  directed  editor  are  currently  under 
development. 

E.  ARCHITECTURAL  DESIGN 

The  architectural  design  for  the  INS  system  does  not  have  to  be  developed 
using  the  SPEC  language,  since  this  step  was  already  accomplished  in  the  PSDL 
development,  for  a  review  see  [Figure  2:p  7],  [Figure  3:p  10]  and  [Figure  4:p.  12],  The 
design  is  ready  tc  be  implemented  at  this  stage. 
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IV.  IMPLEMENTATION 


A.  PREFACE 

Up  to  this  point  we  have  explored  methods  to  create  software  in  an  automated 
fashion.  Since  not  all  tools  are  operational  yet.  the  implementation  of  the  INS  system 
was  done  in  the  traditional  ’manual'  way.  This  approach  is  worthwhile  because  It  gives 
a  good  bases  for  future  work.  When  all  the  tools  become  available,  a  test  case  will 
already  be  available  which  can  be  used  to  compare  automatically  and  manually 
produced  software.  Even  though  the  implementation  was  done  manually,  the  author  tried 
to  stay  as  close  to  the  development  work  done  so  far  as  possible.  Parts  of  the  code 
for  the  INS  system  are  shown  in  this  chapter,  for  the  full  implementation  consult 
Appendix  B.  Actual  code  is  typed  in  bold  face  to  visually  separate  it  from  the  text. 

B.  COMPILER 

The  implementation  was  done  using  two  compilers: 

1.  INTEGRADA 

The  system  runs  on  an  IBM  XT  personal  computer  and  was  used  to  develop 
subcomponents  to  be  integrated  into  the  overall  system  at  a  later  stage. 

INTEGRADA  is  not  only  a  compiler,  but  a  development  environment,  providing 
an  editor  which  can  be  used  as  a  normal  programmer’s  editor  or  as  a  syntax  or 
language  directed  editor.  This  was  considered  useful,  since  the  Ada  language  is  very 
rich  in  its  available  constructs,  and  the  syntax  generation  capability  saved  a  lot  of  time 
in  consulting  the  Ada  language  reference  manual  (ALRM)  [Ref.  10]  and  other  literature. 

Another  feature  of  INTEGRADA  is  the  pretty  printer  which  allows  the  user  to 
format  the  source  code  in  several  ways.  The  option  'Program  Structure'  is  very  helpful 
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for  debugging  purposes  and  the  option  'MIL  STD  1815  A'  [Ref.  10]  was  used  after  all 
the  source  code  had  reached  its  final  stage  to  format  the  documents  in  a  format  as 
described  in  the  ALRM  and  that  is  accepted  in  the  Ada  community. 

2.  VERDIX 

The  target  machine  for  the  final  product  was  a  SUN  workstation,  the  compiler 
available  on  this  system  is  the  VERIDX  Ada  compiler  Version  5.5  for  the  SUN  3.  In 
contrast  to  INTEGRADA  this  compiler  is  a  stand  alone  version,  not  an  environment, 
although  some  tools  are  provided  with  the  system.  To  be  mentioned  are  the  source 
level  debugger  which  was  very  helpful  in  the  implementation  phase  and  the  pretty 
printer. 

C.  CONCURRENCY  AND  EXTENSIBILITY 

During  the  formal  requirements  analysis  the  goal  G1.4  was  derived  (see  also  p.  17) 

G1.4:  The  system  Is  supposed  to  be  highly  concurrent  and  prepared  for  future 
extensions. 

This  goal  was  realized  in  part  during  the  decomposition  of  the  prototype  approach 
by  dividing  the  system  into  four  separate  processes,  which  can  be  executed 
concurrently  (see  also  Figure  3:p.  10).  In  the  implementation  these  processes  are 
implemented  as  four  independent  tasks,  whose  skeletons  are  shown  on  the  next  page. 
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procedure  INS  is 

task  CHECK_KEYBOARD  is 

end  CHICK_KEYBOARD ; 
task  COMPUTE_POSITION  is 

end  COMPUTE_POSITION; 

task  COMPUTE_BEARING_D I STANCE  is 

end  COMP UTE_BEARING_D I STANCE ; 
task  DISPLAx_HANDLER  is 

e 

end  DISPLAY_HANDLER; 
end  ins ; 

This  approach  has  the  inherent  problem  of  data  integrity.  Some  of  the  tasks  operate 
on  the  same  data  elements  and  the  question  is,  how  to  ensure  that  no  two  tasks  try 
to  reference  and  update  the  same  data  element  at  the  same  time,  a  problem  which  is 
new  in  multitasking  environments,  where  a  program  is  no  longer  a  set  of  instructions 
which  are  executed  in  sequence. 

A  solution  was  found  in  an  algorithm  presented  in  [Ref.  11].  It  uses  a  task  with  two 
entries,  one  entry  allows  data  to  be  written  to  a  buffer,  the  other  one  allows  reading 
from  that  buffer.  Since  the  two  ’accept’  statements  are  incorporated  in  a  select 
statement,  only  one  of  them  can  be  executed  at  a  time,  thereby  ensuring  data  integrity. 
This  data  buffer  was  implemented  as  a  generic  package  containing  a  task  type.  Since 
the  package  is  generic,  it  can  be  instantiated  for  different  data  types,  the  task  type 
allows  the  creation  of  several  instances  of  the  same  type.  The  accessibility  of  the  data 
also  provides  for  future  extensions  to  the  system.  The  actual  source  code  used  in  the 
INS  system  is  shown  on  the  next  page. 
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generic 


type  ITEM_TYPE  i«  private; 

package  DATASTORAGE  is 

task  type  BOTrER  is 

entry  STORE (ITEM  :  in  ITEM_TVPE) ; 
entry  RECALL (ITEM  :  out  ITEM_TYPE)  ; 
end  BUTTER; 
end  DATA_STORAGE ; 

package  body  DATA_STORAGE  is 

task  body  BUTTER  is 
DATUM  :  ITEM_TYPE; 
begin 
loop 
select 

accept  STORE  (ITEM  :  in  ITEM_TYPE)  do 
DATUM  :=  ITEM; 
end  STORE; 
or 

accept  RECALL  (ITEM  :  out  ITEM_TYPE)  do 
ITEM  :=  DATUM; 
end  RECALL ; 
end  select ; 
end  loop; 
end  BUTTER; 
end  DATA_STORAGE; 

To  accommodate  ail  buffers  necessary  for  the  INS  system  nine  tasks  which  serve 
as  data  buffers  were  instantiated. 

A  drawback  of  the  multitasking  concept  was  found  during  the  development  of  the 
input  facilities.  Due  to  the  underlying  operating  system  (UNIX)  it  was  necessary  to 
serialize  the  two  tasks  CHECK_KEEYE30ARD  and  DISPLAYJHANDLER,  which  doesn't 
affect  the  functionality  of  the  overall  system  nor  its  efficiency  or  speed.  However  the 
implementation  is  very  sytem  dependant  for  this  part,  which  degrades  portability.  Since 
problems  of  this  nature  were  not  the  main  subject  for  this  research  they  were  not 
investigated  any  further,  which  might  have  resulted  in  other  solutions. 
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D.  TIMING  CONSTRAINTS 

During  the  prototype  development,  time  constraints  were  placed  on  some  of  the 
operators.  To  show  the  principle  of  implementing  such  constraints,  task 
COMPUTE_BEAR!NG_AND_DISTANCE  is  discussed. 

task  body  COMP OTE_BEARING_D I STANCE  is 
bagin 
loop 

TASK_ START  :=  CLOCK; 

—  starts  a  stopwatch  local  to  this  task 

--  statements  to  execute  the  necessary  computations 

TASK_DONE  :=  CLOCK; 

--  stops  the  stopwatch 
delay  1.0-  (TASK_DONE  -  TASK_START) ; 

--  pauses  the  task 

end  loop; 

end  COMPUTE_BEARING_DISTANCE; 

When  the  task  enters  the  loop,  a  stopwatch  local  to  this  task  is  started.  After  all  the 
computations  are  executed  and  just  before  the  end  of  the  loop  the  stopwatch  is 
stopped.  The  task  is  then  delayed  for  a  period  of  one  second  minus  the  time  it  took  to 
execute  the  loop,  thereby  creating  a  repetition  time  or  period  of  one  second  for  the 
loop.  Should  the  difference  be  negative,  which  indicates  that  the  loop  needed  more  than 
one  second  to  executg,  the  task  will  not  be  delayed  and  the  next  loop  execution  will 
start  right  away.  According  to  the  Ada  standard,  this  does  not  necessarily  mean  the 
next  loop  execution  starts  exactly  one  second  after  the  last  one,  but  that  the  task  is  put 
in  a  'ready'  state,  waiting  for  resources.  When  the  necessary  resources  are  available, 
the  task  is  put  into  the  'running'  state  and  execution  starts. 
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E.  PACKAGING 


The  system  was  divided  into  a  main  program  and  four  packages.  Two  of  the  four 
packages  are  generic  and  were  instantiated  in  multiple  Instances. 

•  procedure  INS 

•  package  NAVUTIL 

•  generic  package  FLOATING_POINT_UTILITIES 

•  package  TERMINAL 

•  generic  package  DATA_STORAGE 

Packages  NAVUTIL,  FLOATING_POINT_UTILITIES  and  TERMINAL  represent 
collections  of  resources,  package  DATA_STORAGE  implements  a  buffer  data  type.  In 
addition  to  these  user  defined  packages  five  additional  packages  supplied  with  the 
compiler  were  used: 

•  package  TEXTJO 

•  package  MATH 

•  package  CURSES 

•  package  IOCTL 

•  package  SYSTEM 

1.  Generic  package  DATA_STORAGE 

This  package  was  already  discussed  in  Chapter  IV.C.  Here  an  example  of  its  use 
is  given.  A  navigation  system  needs  the  capability  to  store  a  geographical  position, 
consequently  a  buffer  was  instantiated  for  this  purpose: 

package  POSITION_8TORAGE  is  new  DATA_STORAGE (POSITION) ; 

where  POSITION  is  a  user  defined  record  data  type.  This  makes  a  task  type  BUFFER 
available  for  data  type  POSITION.  Then  a  variable  of  that  data  type  is  declared: 

WP_BOTTER  :  array  (0  ..  MAXJfAYPOIHTS)  of  POSITION  STORAGE . BUTTER; 
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The  position  is  stored  in  one  of  the  array  elements.  An  example  of  its  usage  is  the 
task  for  computing  the  PRESENT_POSITION  shon  below. 

tmuX.  body  COMPOTEJPOSITION  is 
begin 

WP_BUTFER(0) . RECALL (PRESENT_POSITION) ; 

—  retrieves  the  old  PRESENT_POSITION  from  its  buffer 

—  statements  to  do  the  calculation 

WP_BUFFER (0) . STORE (PRESENT_POSITION) ; 

--  stores  the  new  PRESENT_POSITION  into  its  buffer 

end  COMPUTE_POSITION; 

2.  Package  TERMINAL 

Terminal  is  the  only  package  that  contains  hardware  dependant  code,  hence  the 
specification  and  the  body  were  located  in  separate  files.  If  the  system  is  to  be  ported 
to  another  system,  which  has  different  terminal  capabilities,  the  body  of  package 
TERMINAL  is  the  only  part  that  needs  to  be  recoded  and  recompiled.  The  current 
version  contains  options  to  run  the  system  on  a  SUN  workstation  or  a  VT  100  terminal. 

3.  Generic  package  FLOATING_POINT_UTlLinES 

The  FLO  ATI  NG_POI  NT_UTI  LITI ES  package  contains  some  mathematical 
functions  not  provided  in  the  standard  math  library.  Most  of  the  algorithms  were  taken 
from  [Ref.  12].  The  functions  listed  below. 

functio-  INTEGER_PART 
function  RKAL_PART 
function  FLOOR 
function  CEILING 
function  IS_POSITIVE 
function  ISJNEGATIVE 
function  INT_TO_CHAR 
function  CHAR  TO  I NT 
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These  functions  were  primarily  used  in  conjunction  with  input/output  operations, 
which  are  all  done  in  string  or  character  format,  to  allow  more  control  over  the  screen 
layout.  A  sample  screen  is  shown  in  the  user  manual  in  Section  IV. F  of  this  thesis. 

4.  Package  NAVUT1L 

All  the  functions  used  to  perform  the  necessary  computations  In  the  INS  system 
are  located  in  this  package.  It  also  includes  the  functions  for  input  and  output  of 
navigation  specific  data. 

procedure  GETJPOSITION 
procedure  GET_SPEED; 
procedure  GET_COURSE ; 
procedure  DISPLAY_POSITION 
procedure  BEARING_D I STANCE 
procedure  UPDATE_POSITION 

As  an  example  for  an  input  operation  procedure  GET_COURSE  is  shown  here. 
The  input  is  supposed  to  be  in  the  form  DDD.D,  where  D  is  a  digit  from  ’O'  to  '9'. 

procedure  GET_COURSE  is 


begin 


--  read  in  the  string 

GET (COURSE_S) ; 

--  check  for  period  in  the  correct  place 

if  COURSERS (4)  *  then 
StJCCl  :=  TRUE: 

else 

SUCC1  :=  FALSE; 
end  if; 

--  convert  string  to  a  variable  of  type  FLOAT 

COURSE_F  :=  FLOAT (CHAR_TO_INT (COURSE_S (1) )  *  100  + 
CHAR_TO_INT (COURSE_S (2) )  *  10  +  CHARJTO  I NT (COURSE_S (3) ) )  + 
FLOAT <CHAR_TO_INT (COURSE_S (5) ) )  *  0.1;  ” 

—  check  that  value  is  in  range 
if  COURSEJT  >=0.0  end  COURSE_F  <  359.9 
then  SUCC2  :=  SUCC1  end  TRUE; 
else 

SUCC2  :=  FALSE; 
end  if; 


end  GET  COURSE; 
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The  remaining  input  operations  for  the  system  are  similar,  and  differ  only  in  the 
input  string  length  and  the  checks  to  be  passed,  before  an  input  is  accepted  as  valid. 
These  checks  are  embedded  in  loops,  which  can  only  be  exited  on  a  valid  input. 

F.  USER  MANUAL 
1.  Start  Up 

Only  one  file  named  'INS'  is  necessary  to  run  the  system,  it  is  invoked  without 
any  parameters.  The  system  interacts  with  the  user  only  via  the  keyboard.  Although 
some  error  checking  is  implemented  in  the  system,  some  errors  are  unrecoverable  at 
run  time.  In  such  cases  program  execution  has  to  be  aborted  by  pressing  the 
'CONTROL'  key  and  the  'C'  key  at  the  same  time.  After  an  internal  start  up  sequence 
the  user  is  presented  with  the  screen  shown  below. 


INS  SIMULATOR 


LATITUDE  NOOOO.O  LONGITUDE  WOOOOO.O 


ENTER  /  UF  DATE 


DISPLAY 


[1]  PRESENT  POSITION 

[2]  WAYPOINT 

[3]  COURSE 

[4]  SFEED 


[6]  PRESENT  POSITION 

[7]  WAYPOINT 

[8]  COURSE  /  SPEED 

[9]  BEARING  /  DISTANCE 


The  user  may  now  enter  a  start  position.  The  format  for  entering  the  information 
is  always  the  same  as  presented  on  the  screen,  e.g.  to  enter  the  latitude: 

•  Enter  'N'  for  north  or  'S'  for  south  in  upper  or  lower  case  letters. 
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•  Enter  four  digits,  two  for  degrees  of  latitude  and  two  for  minutes  of  latitude. 

•  Enter  a  decimal  point. 

•  Enter  one  digit  for  decimal  fractional  minutes  of  latitude. 

After  the  start  position  is  entered,  the  user  is  prompted  to  enter  course  and 
speed  values.,  o  >an  the  program  takes  over  control  and  automatically  selects  option 
number  [6]  (DISPLAY  PRESENT  POSITION).  This  marks  the  end  of  the  start  up 
sequence.  The  system  will  continue  to  display  the  updated  present  position  until  the 
user  selects  another  choice  from  the  menu,  which  is  continuously  displayed  on  the 
screen. 

2.  Run  Time  Options 

Generally  an  option  stays  in  effect  until  another  one  is  selected.  The  system 
updates  the  screen  once  every  second  as  long  as  it  is  in  one  of  the  DISPLAY  options 
[6]  to  [9],  In  the  ENTER  /  UPDATE  options  the  user  can  take  as  much  time  as  he 
needs  to  complete  an  input.  The  following  options  are  provided: 

•  ENTER  /  UPDATE 

•  [1]  PRESENT  POSITION  To  enter  a  present  position  into  the  system,  behaves 

as  described  in  the  start  up  section. 

•  [2]  WAYPOINT  To  enter  up  to  three  waypoints,  numbered  1  to  3. 

After  selection  prompts  for  a  waypoint  number,  then 
the  position  can  be  entered.  The  default  value  for  all 
three  waypoints  is  NOOOO.O  W00000.0. 

•  [3]  COURSE  To  enter  a  course,  which  is  one  of  data  elements 

necessary  for  the  system’s  computations.  This  is  an 
artificial  option,  which  not  be  available  on  an 
operational  system,  since  COURSE  and  also  SPEED 
would  be  provided  by  other  aircraft  systems. 

•  [4]  SPEED  To  enter  a  speed  value  ranging  from  1  to  499  Kts. 

•  [5]  STEER  TO  WAYPOINT  To  select  one  of  the  waypoints  as  the  next 

destination.  Once  a  waypoint  has  been  selected  the 
bearing  and  distance  calculations  refer  to  this 
waypoint.  The  default  value  is  1 . 
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•  DISPLAY 


•  [6]  PRESENT  POSITION  To  display  the  present  position  of  the  aircraft. 

•  [7)  WAYPOINT  To  display  the  coordinates  of  a  waypoint,  which  has 

been  selected  with  option  [5]. 

•  [8]  COURSE  /  SPEED  To  display  the  present  values  for  course  and  speed. 

•  [9]  BEARING  /  DISTANCE  To  display  a  true  bearing  and  distance  from  the 

aircraft’s  present  position  to  a  waypoint,  which  has 
been  selected  with  option  [5J. 
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V.  CONCLUSIONS 


A.  THE  ADA  LANGUAGE 

Ada  as  a  programming  language  is  on**  of  the  mo**  powerful  languages  available 
today,  which  has  good,  but  also  bad  attributes  associated  with  it. 

1.  Object  Oriented  Programming  (OOP) 

The  constructs  available  in  the  language  give  it  characteristics  of  object  oriented 
programming  language.  Packages  are  an  example  for  data  abstraction  and 
encapsulation;  they  enable  the  programmer  to  create  abstract  data  types  in  a  true 
fashion.  If  private  types  or  even  limited  private  types  are  used  in  the  implementation, 
the  only  operations  available  for  an  abstract  data  type  are  those  defined  by  the 
programmer,  or  in  the  case  of  private  types  additionally  the  ’assignment’  and  'check  for 
equivalence’  operation. 

A  major  ingredient  of  OOP  is  inheritance.  The  'with'  statement  in  Ada  allows  a 
a  variable  or  object  of  a  certain  type  to  inherit  characteristics,  which  e.g.  might  be 
defined  in  a  package. 

2.  Strong  Typing 

Another  characteristic,  strong  typing,  is  a  very  important  aspect  in  connection 
with  large  software  systems,  which  are,  among  others,  one  reason  for  Ada’s  existence. 
Strong  typing  can  make  programming  a  very  cumbersome  task,  since  many  type 
conversions  may  be  necessary.  On  the  other  hand  it  far  outreaches  this  disadvantage, 
when  it  comes  to  debugging  a  program  as  all  programming  errors  that  result  in  type 
inconsistencies  are  detected  at  compile  time  already.  For  languages  that  support  no  or 
almost  no  static  type  checking  e.g.  ’C’  this  checking  must  be  done  at  run  time.  But  then 
the  amount  of  typing  errors  detected  depends  on  the  data  on  which  the  program 


operates.  This  is  one  fact  that  makes  ’C',  from  a  software  engineering  point  of  view, 
unsuitable  for  large  software  systems. 

3.  Information  Hiding 

Information  hiding  is  implemented  very  well  in  the  Ada  language.  Good  examples 
of  this  are  the  package0  provided  with  the  different  compilers.  The  user  is  only  provided 
with  the  interface  or  specification  of  the  packages,  which  is  always  the  same  for  a 
certain  package.  Whereas  the  sourcecode  for  the  body,  which  may  be  different  for  each 
implementation,  is  usually  not  accessible. 

4.  Concurrency 

Ada  makes  multitasking  possible  only  using  constructs  defined  within  the 
language  in  the  form  of  tasks  and  other  related  constructs,  like  rendezvous  and  the 
pragma  ’priority’.  This  should  be  a  good  asset  in  terms  of  efficiency  and  performance, 
however,  as  of  now,  no  compiler  is  available  for  any  multi  processor  system,  but  that 
fact  should  be  eliminated  by  time,  since  compilers  have  already  been  announced  for 
multiprocessor  systems. 

5.  Portability 

Portability  is  a  more  negative  aspect  of  the  Ada  language,  even  thougn  the  Ada 
Joint  Programming  Office  keeps  a  strict  eye  on  the  quality  of  the  available  compilers 
by  validating  only  those  compilers  which  successfully  work  on  a  set  of  test  programs. 
At  first  glance  this  should  ensure  portability.  The  problem  lies  in  the  specification  of 
the  language,  which  is  manifested  in  the  ALRM  [Ref.  10]  and  which  in  some  places 
leaves  too  much  leeway  for  the  implementation  of  the  compiler.  The  best  example  is 
the  pragma  'priority'  which  allows  the  assignment  of  relative  importance  on  a  set  of 
tasks,  thereby  controlling  their  order  of  execution.  The  pragma  has  to  implemented  in 
every  compiler,  however  the  range  of  legal  values  is  left  to  the  particular 
implementation,  which  results  in  quite  different  values.  Since  not  all  compilers  provide 


this  information  in  their  documentation,  a  small  program  to  check  those  values  on  any 
compiler,  regardless  of  the  documentation  is  shown  below. 

with  t«xt_io; 
use  text  io; 
with  system; 

procedure  prio  is 

package  priority_io  is  new  integer_io (system. priority)  ; 
use  priority_io; 

begin 

new_pege ; 

put ("min  value  for  priority  :  "); 
put (system. priority'  first)  ; 
new_line; 

put ("max  value  for  priority  :  "); 
put (system. priority ' last) ; 
new_line : 
end; 


A  test  am  on  three  different  compilers,  which  were  available  at  the  time  of  this 
research  produced  the  following  results. 

COMPILER  VALUES  FOR  PRAGMA  PRIORITY 

AdaVantage  Version  2.0  1  ..  20 

INTEGRADA  Version  4.01  0  ..  0 

Verdix  Version  5.5  0  ..  99 

This  is  only  one  example  of  a  deficiency  in  the  language  specification. 

The  next  factor  contributing  to  Ada’s  bad  portability  is  the  lack  of  standard 
libraries,  provided  with  the  compilers.  As  an  example  one  might  expect  a  package  for 
mathematical  functions,  which  are  not  included  in  the  language  standard.  Again  when 
comparing  the  three  above  mentioned  compilers  we  have  the  following  picture: 

AdaVantage  INTEGRADA  Verdix  Ver5.5 


Package  name  mathjib  mathiib  math 

function  ARCTAN{X)  atan(x)  arctan(x)  arctan(x) 
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6.  Hard  Real  Time  Systems 

As  shown  in  Chapter  IV. D  on  page  34  the  programmer  has  possibilities  to 
influence  the  execution  timing  of  a  programming  unit;  the  example  also  showed,  that 
a  delay  is  only  a  minimum  waiting  period,  meaning,  that  there  is  no  way  to  tell  the 
maximum  waiting  time,  which  is  unacceptable  in  hard  real  time  systems,  where 
deadlines  have  to  be  met.  This  aspect  of  the  language  is  a  separate  research  area  in 
itself  and  shall  not  be  exploited  any  further  here.  The  interested  reader  can  find  further 
information  in  [Ref.  13,  14,  15,  16,  17]. 

7.  Final  Comment 

Summarizing  the  points  made  above,  the  Ada  language  is  very  powerful  and 
suited  for  its  purpose.  The  negative  points  should  not  be  considered  as  an  attempt  to 
detract  from  that  fact,  but  is  an  attempt  by  the  author  to  show  some  areas  where 
further  improvement  is  needed. 

B.  SPECIFICATION  AND  PROTOTYPING 

The  languages  SPEC  and  PSDL  are  not  for  programming  purposes.  Conceptually 
they  reside  at  a  higher  level  of  abstraction  than  programming  languages.  The 
development  team  no  longer  describes  a  program  in  terms  of  HOW  to  complete  a 
certain  task,  but  by  specifying  WHAT  tasks  are  to  be  completed.  Due  to  their  complexity 
and  size,  large  software  systems  cannot  be  realized  using  traditional  programming 
languages  and  software  engineering  techniques  only.  No  single  person  can  comprehend 
a  complete  system,  therefore  the  need  for  communication  between  all  people  involved 
in  the  development  of  such  a  system  arises.  Furthermore  it  is  becoming  more  and 
more  difficult  to  prove  the  correctness  of  a  program,  or  to  do  at  least  some  testing  to 
insure  its  correctness  to  a  certain  level.  SPEC  is  one  attempt  to  solve  this  problem.  It 
is  suitable  to  develop  the  specification  for  a  program  instead  of  the  program  itself.  Since 
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the  language  is  strictly  based  on  mathematical  rules  it  has  the  potential  to  solve  the 
'proof  of  correctness’  problem  or  at  least  bring  it  closer  to  a  solution. 

The  problem  with  all  specification  languages,  SPEC  is  only  one  of  them,  lies  in 
their  application.  As  the  small  example,  developed  in  Chapter  III,  shows,  specifications 
grow  rapidly  and  become  incomprebendable  at  the  same  pace.  It  is  obvious  that 
automated  tools  are  necessary  to  use  SPEC  on  a  production  level  to  keep  track  of  the 
development  stage  and  to  insure  the  completeness  and  consistency  of  a  specification. 
As  already  mentioned  some  of  those  tools  are  presently  under  construction.  Their 
development  is  supported  by  the  mathematical  foundation  of  SPEC,  a  negative  aspect 
however  is  the  fact  that  not  every  specification  can  be  automatically  translated  into 
executable  code. 

A  type  checker  is  needed  to  check  that  all  types  used  within  a  specification  at 
different  levels  of  decomposition  conform,  whereas  a  syntax  directed  editor  must  take 
care  of  the  completeness  and  syntactical  correctness  of  all  language  constructs  used. 
Another  very  important  tool  is  a  development  database,  which  retains  the  development 
up  to  the  current  stage.  This  is  important  to  provide  the  capability  to  go  back  and  forth 
between  different  levels  of  decomposition. 

SPEC  addresses  the  problems  of  reliability,  modifiability  and  other  related  problems 
mentioned  in  the  Introduction.  The  other  main  problem  areas  in  software  development 
are  cost  and  feasibility;  PSDL  is  an  attempt  to  cope  with  them.  It  aids  the  development 
process.  After  the  requirements  for  a  project  have  been  manifested,  PSDL  can  be  used 
to  construct  a  prototype  which  in  the  long  run  will  be  a  piece  of  executable  code.  PSDL 
does  not  have  a  mathematical  foundation  like  SPEC,  hence  it  cannot  be  used  to  attack 
the  'correctness'  problem. 

The  tool  development  for  PSDL  has  proceeded  much  further  than  that  for  SPEC. 
Even  though  it  is  not  possible  to  create  an  executable  prototype  without  manual 
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interaction  at  the  present  time,  tools  already  available  are  instrumental  for  the  completed 
system  as  their  application  demonstrated  in  Chapter  II. 

C.  THE  COMBINATION  OF  PSDL  AND  SPEC 

So  far  SPEC  and  PSDL  have  been  examined  as  separate  systems.  The  latest 
development  in  the  software  engineering  discipline  is  marked  by  DARPA's  (Defence 
Advanced  Research  Projects  Agency)  decision  to  create  a  language  on  top  of  Ada 
[Ref.  18].  This  language  is  to  provide  all  the  capabilities  presently  designed  in  SPEC 
and  PSDL.  Future  emphasis  should  be  placed  on  the  fusion  pf  the  two  languages 
combing  their  capabilities.  Care  must  be  taken  that  the  resulting  language  is  not  just  a 
superset,  which  contains  the  two  languages  as  complete  subsets.  Overlapping 
constructs  and  methods  must  be  eliminated.  Once  a  minimal  version  of  the  system  is 
operational,  it  can  be  used  to  improve  on  itself,  which  should  speed  up  the  development 
dramatically. 
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APPENDIX  A.  INS  SPECIFICATION  IN  PROTOTYPE  DESCRIPTION  LANGUAGE  (PSDL) 


OPERATOR  INS 


SPECIFICATION 


INPUT  Present_Position 
Course 
Speed 
WP_1 
WF_2 
WP_3 

WP_number 
New_time 
New  choice 


POSITION; 

FLOAT; 

INTEGER; 

POSITION; 

POSITION; 

POSITION; 

INTEGER; 

TIME; 

INTEGER; 


OUTPUT Pr esent_Position 
Course 
Speed 
WF_1 
WF_2 
WP_3 

WF  number 

Bearing 

Distance 


POSITION; 

FLOAT; 

INTEGER; 

POSITION; 

POSITION; 

POSITION; 

INTEGER; 

FLOAT; 

FLOAT; 


END 


IMPLEMENTATION  GRAPH 


Old_choice . Check_keyfcoard  -->  Check_keyboard 

01d_chcice . Check_keyboard  — >  Display_handler 

New_chcice . Check_keyboard  -->  Display_handler 

Bear ing . Compute_bearing_distance  -->  Display_handler 

Distance . Compute_bearing_distance  — >  Display_handler 

Speed  .  Display_handler  -->  EXTERNAL 

Speed . Display_handler  — >  Compute_pcsition 

Course .Disp!ay_handler  -->  EXTERNAL 

Course . Displav_handler  -->  Compute_position 

01d_Fos ition . Display_handler  -->  Compute_position 

Bear ing . Display_handler  -->  EXTERNAL 

Distance . Dispiay_handier  -->  EXTERNAL 

WF_1 .Display_handler  -->  EXTERNAL 

WP_2 . Display_handler  — >  EXTERNAL 

WP_3 . Display_handler  — >  EXTERNAL 

WP_number . Display_handler  -->  Compute_bearing_distance 

WF_3 . Display_handler  -->  Compute_bear ing_distance 

«r_2 . Display_handler  -->  Compute  bearing_distance 

WP_1 . Display_handler  -->  Compute_bearing_diatance 

WP_number . Display_handler  -->  EXTERNAL 

Most_recent_position . Display_handler  -->  EXTERNAL 

New_chcice . EXTERNAL  -->  Check_keyboard 

01d_time . Compute_position  -->  Compute_position 

Most_recent_position . Compute^position  — >  Display_handler 

Mcst_recent_position .Compute_position  — >  Compute_bear ing_distance 

WP_number . EXTERNAL  -->  Display_handl er 

New_time.EXTEP.NAL  -->  Compute_position 

WP_1  .EXTERNAL'  — >  Display_handler 


WF_2 .EXTERNAL  — >  Display_handler 
WP_3 .EXTERNAL  — >  Display_handler 
Present_Position .EXTERNAL  — >  Display_handler 
Course .EXTERNAL  — >  Display_handler 
Speed . EXTERNAL  -->  Display_handler 

DATA  STREAM 


Bearing 

FLOAT; 

Distance 

FLOAT; 

Speed 

INTEGER; 

Course 

FLOAT; 

WP  number 

INTEGER; 

WP  3 

POSITION; 

WF  2 

POSITION; 

WF_1 

POSITION; 

Old  Position 

POSITION; 

Old  choice 

INTEGER; 

New  choice 

INTEGER; 

Most  recent_position 

POSITION; 

CONTROL  CONSTRAINTS 

OPERATOR  DISPLAY'_HANDLER 

PERIOD  Is 

OPERATOR  COMFUTE_BEARING_DISTANCE 
PERIOD  Is 

OPERATOF  COMFUTE_POS ITION 
PERIOD  Is 

DESCRIPTION 

(This  is  the  root  operator.  It  is  composite  and  consists  of  the 
composite  operator  DISPLAY_HANDLER  and  the  atomic  operators 
CHECK_KEYBOARD,  COMP UTE_BEARING_D I STANCE  and  COMPUTE_POS ITION ) 

END 


OP ERATOP.  CHECK_KEYBCARD 

SPECIFICATION 

INPUT  New_chcice 

OUTFUT  01d_chcice 
New_choice 

STATE  Old  choice 


:  INTEGER; 

:  INTEGER; 

:  INTEGER; 

:  INTEGER  INITIALLY  6; 


END 

IMPLEMENTATION  ADA  CHECF_KEYBOARD 

(The  atomic  operator  CHECK_KEYBOARD  requires  visibility  to  datastreams 
OLD_CHCICE  and  NEW  CHOICE  in  IN  ) 


END 
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OFEPATOR  DISFLAY_HANDLER 
SPECIFICATION 


INPUT 


OUTPUT 


Old  choice 

INTEGER; 

New  choice 

INTEGER; 

Bearing 

FLOAT; 

Distance 

FLOAT; 

Most  recent_position 

POSITION; 

Speed 

INTEGER; 

Course 

FLOAT; 

WP  number 

INTEGER; 

WP  1 

POSITION; 

WF  2 

POSITION; 

WP  3 

POSITION; 

Present  Position 

POSITION; 

Speed 

INTEGER; 

Course 

FLOAT; 

Bearing 

FLOAT; 

Distance 

FLOAT; 

WF  1 

POSITION; 

WF  2 

POSITION; 

WF  3 

POSITION; 

WF  number 

INTEGER; 

Old  Position 

POSITION; 

Most  recent__pcsition 

POSITION; 

END 

IMPLEMENTATION  GRAPH 

Preser.t_Pcsition  .Enter_present_position  -->  WP_buffer_0 

WF_1 . Enter_waypoint  -->  WP_buffer_l 

WP_2 .Enter_waypcint  -->  WF_buffer_2 

WF_3 . Enter_waypoint  —  >  Wp_buffer_3 

Course  . Intercourse  -->  Course_buf  fer 

Speed .  E.nter_speed  -->  Speed  buffer 

WF_number . Enter_steer_tc_waypcint  -->  WP_number_buf f er 

Most_Recent_F  sition  .  Display_jpre3ent_p0siti.cn  -->  EXTERNAL 

WF_Number . Display_waypcint  -->  EXTERNAL 

WP_1 . Display_waypoint  -->  EXTERNAL 

WF_2  . Display  waypoint  -->  EXTERNAL 

WF_3 .Display_waypeint  -->  EXTERNAL 

Bear ing . Display_bearing_and  distance  -->  EXTERNAL 
Distance .Display_bearing_and_distance  — >  EXTERNAL 
WP_Number  .  Drsplay_bearing_and_distance  -->  EXTERNAL 
Course . D ispl ay_cour se_and_speed  -->  EXTERNAL 
Speed . Display_ccurse_and_speed  -->  EXTERNAL 

Most_Recent_Position .WF_buf f er_0  — >  Display_present_position 

Most_Recent_Pcsition . WP_buf f er_0  -->  EXTERNAL 

01d_Positicn .WF_buffer_0  — >  EXTERNAL 

WF_1 .WF_buf f er_l  -->  Display_waypcint 

WF_2 . WF_buf f er_2  — >  Display_waypoint 

WP_3 . WF_buf fer_3  -->  Display_waypoint 

Bearing. Bearing_buf fer  -->  DispXay_bearing_and_distance 

Di stance . Distance_bu f fer  — >  Display  bearing  and  distance 

Course . Ccurse_buf fer  -->  Display_ccurse  and  speed 

Speed . Speed_buf fer  -->  Display_course  and  speed 

WP_number . WF_number_buf f er  — >  Display  waypoint 

WF_Number . WF_number_buf f er  — >  Display  bearing  and_distance 

Course . EXTERNAL  -->  Enter_ccurse 

Speed . EXTEFliAL  -->  Enter_speed 

WF_n umber  .  EXTERNAL  — >  Enter  steer  to  waypoint 
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Bearing. EXTERNAL  — >  Bearing_buf fer 

Distance .EXTERNAL  — >  Distance_buf fer 

Present  Position  .EXTERNAL  — >  Enter_preser.t_poaition 

Most_Recent_Position .EXTERNAL  — >  WP_buffer_0 

WP_N umber . EXTERNAL  -->  Enter_waypoint 

WP_1 .EXTERNAL  — >  Enter_waypoint 

WP_2 . EXTERNAL  -->  Enter_waypoint 

WP_3 . EXTERNAL  — >  Enter_waypoint 

DATA  STREAM 


Present  Position 

POSITION 

WP  1 

POSITION 

WP  2 

POSITION 

WP_3 

POSITION 

Course 

FLOAT; 

Speed 

INTEGER; 

WP  number 

INTEGER; 

Most  Recent  Position 

POSITION 

Bearing 

FLOAT; 

Distance 

FLOAT; 

WF  Number 

INTEGER; 

DESCRIPTION 

{The  composite  operator  DISPLAY_HANDLER  CONSISTS  of  the  atomic 
operators  ENTER_PRESENT_POSITION,  ENTER_WAYPOINT,  ENTER_CCURSE, 
ENTER_SPEED,  ENTER_STEER_TO  WAYPOINT,  DISPLAY  PRESENT_POSITION, 
DISPLAY  WAYPOINT,  DISPLAY_BEARING_AND_D I STANCE , 

DISPLAY_COURSE_AND_SPEED,  WP_BUFFER_0,  WP_BUFFER_I ,  WP_B0FFEK_2, 
WF_BUFFER_3 ,  BEARING_BUFFER,  DISTANCE_BUFFER,  COURSE_BUFFER, 
SPEED_BUFFER  and  WP_NUMBER_BUFFER.  It  requires  visibility  to  all  data 
streams  in  INS) 


END 


OPERATOR  COMP UTF_BEARING_D I STANCE 

SPECIFICATION 

INFUT  WP_number 
WI  _3 
WP_2 
WF_1 

Mcst_recent_po.’-  Ition 

OUTPUT  Bearing 
Distance 

END 


INTEGER; 

POSITION 

POSITION 

POSITION 

POSITION 

FLOAT; 
FLOAT ; 


IMPLEMENTATION  ADA  COMPUTE  BEARING  DISTANCE 


{The  atomic  operator  COMPUTE_BEARING  DISTANCE  requires  visibility  to 
datastreams  MOST_RECENT_POSITION,  BEARING,  DISTANCE,  WP_1,  WF_2,  WP_3  and 
WP  NUMBER  in  INS ) 


END 


50 


OFERATOR  COMPUTE  POSITION 


SPECIFICATION 

INPUT  Speed 
Course 

01d_Fosition 

New_time 

OUTPUT  Most_recent_position 
STATE  Old  time 


:  INTEGER; 

:  FLOAT; 

:  POSITION; 
:  TIME; 

:  POSITION; 


:  TIME; 


END 

IMPLEMENTATION  ADA  COMPUTE_POS ITION 

(The  atomic  operator  COMPDTE_POSITION  requires  visibility  to  datastreams 
COURSE,  SPEED,  OLD  POSITION  and  MOST_RECENT-POSITION  in  INS) 


END 


OFERATOF.  ENTEF_PRESENT_POS ITION 
SPECIFICATION 

INPUT  Present_Fosition  :  POSITION; 

OUTPUT  Present  Position  :  POSITION; 


END 

IMPLEMENTATION  ADA  ENTER_PRESENT_POS ITION 

(The  atomic  operator  ENTER_PRESENT_POSITION  requires  visibility  to 
datast  ream  PRESENT  POSITION  in  DISPLAY  HANDLER) 


END 


OPEFA.TOF  WP_BUFFEP_0 

SPECIFICATION 

INPUT  P r esent_F os i t ion 

Most_recent_position 

OUTPUT  01d_Fosition 

Most_r ecent_position 


:  POSITION; 
:  POSITION; 

;  POSITION; 
:  POSITION; 


END 

IMPLEMENTATION  ADA  WP_BUFFER_0 

(The  atomic  operator  WP__BUFFEF,_0  requires  visibility  to  datastreams 
PRESENT  POSITION,  MOST  RECENT  POSITION  and  OLD  POSITION  in  DISPLAY  HANDLER) 


END 
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OPERATOR  ENTER_WAYPOINT 
SPECIFICATION 


:  INTEGER; 

:  POSITION; 
:  POSITION; 
:  POSITION; 

:  POSITION; 
:  POSITION; 
:  POSITION; 


END 

IMPLEMENTATION  ADA  ENTER  WAYPOINT 


INPUT  WP_n umber 
WP_1 
WF_2 
WP_3 

OUTPUT  WP_1 
WF_2 
WP  3 


(The  atomic  operator  ENTER_WAYPOINT  requires  visibility  to  datastreams  WP_1 , 
WP _2,  WF_3  and  WP_NUMBEP.  in  DISPLAY_HANDLER) 

END 


OFERATCR  WF_BDFFEF_1 
SPECIFICATION 

INPUT  WE_1  :  POSITION; 

OUTPUT  WP_1  :  POSITION; 

END 

IMPLEMENTATION  ADA  WP_BUFFER_1 

(The  atomic  operator  WF_BUFFEF_1  requires  visibility  to  datastream  WF  1  in 
D I  St  jjAY_HAND LE  R } 

END 

OPERATOR  WF_BUFFEP_2 
SPECIFICATION 

INPUT  WP_2  :  POSITION; 

OUTPUT  WP_2  :  POSITION; 

END 

IMPLEMENTATION  ADA  WF_BUFFEF_2 

(The  atomic  operator  WP_B'JFFEF_2  requires  visibility  to  datastream  WP_2  in 
DISFLAY_HANDLER) 

END 


52 


OPERATOR  WF_BUFFER_3 
SPECIFICATION 

INPUT  WP_3  :  POSITION; 

OUTPUT  WP  3  :  POSITION; 

END 

IMPLEMENTATION  ADA  WP_BUFFER_3 

(The  atonic  operator  WP_BUFFER_3  requires  visibility  to  datastream  WP_3  in 
D I SP LAY_HANDLER ) 

END 

OPERATOR  ENTER_COURSE 
SPECIFICATION 

INPUT  Course  :  FLOAT: 

OUTPUT  Course  :  FLOAT; 

END 

IMPLEMENTATION  ADA  ENTER_COURSE 

(The  atomic  operator  ENTER_COURSE  requires  visibility  to  datastream  COURSE 
in  D I S P LAY_HAN D LEP. ) 

END 

OPERATOR  COURSE_BUFFEF. 

SPECIFICATION 

INPUT  Course  :  FLOAT; 

OUTPUT  Course  :  FLOAT; 

END 

IMPLEMENTATION  ADA  COURSE_BUFFER 

(The  atomic  operator  COURSE_BUFFER  requires  visibility  to  datastream  COURSE 
in  DISFLAY_HANDLER) 

END 
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OPERATOR  ENTER_SPEED 
SPECIFICATION 

INPUT  Speed  :  INTEGER; 

OUTPUT  Speed  ;  INTEGER; 

END 

IMPLEMENTATION  ADA  ENTER_SPEED 

{The  atomic  operator  ENTER_SPEED  requires  visibility  to  dataatream  SPEED  in 
D I SP LAY_HANDLER } 

END 

OPERATOR  SPEED_BUFFER 
SPECIFICATION 

INFUT  Speed  :  INTEGER; 

OUTPUT  Speed  :  INTEGER; 

END 

IMPLEMENTATION  ADA  SPEED_BUFFER 

{The  atomic  operator  SPEED_BUFFER  requires  visibility  to  datastream  SPEED  in 
DISPLAY_HANDLER) 

END 

OPERATOR  ENTE  R_S  TE  EP._To_V.’A  YP  0 1 NT 
SPECIFICATION 

INPUT  WF_number  :  INTEGER; 

OUTPUT  WF_number  :  INTEGER; 

END 

IMPLEMENTATION  ADA  ENTER_STEER_TO_WAYPOINT 

{The  atomic  operator  ENTER_STEER_TO_WAYPOINT  requires  visibility  to 
datastream  WF_NUMBER  in  DISPLAY_HANDLER j 

END 
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OPERATOR  WP  NUMBER  BUFFER 


SPECIFICATION 

INPUT  WP_number 
OUTPUT  WP  number 


:  INTEGER; 
:  INTEGER; 


END 

IMPLEMENTATION  ADA  WP_NUMBER_BUFFER 

(The  atomic  operator  WP_NUMBER_BUFFER  requires  visibility  to  datastream 
WP  NUMBER  in  DISPLAY  HANDLER) 


END 


OPERATOR  DISPLAY_PRESENT_POSITION 
SPECIFICATION 

INPUT  Most_recent_position  :  POSITION; 

OUTPUT  Most_recent_position  :  POSITION; 


END 

IMPLEMENTATION  ADA  DISPLAY_PRESENT_POSITION 

{The  atomic  operator  DISPLAY_PRESENT_J?OSITION  requires  visibility  to 
datastream  MOST_RECENT_POSITION  in  DISPLAY_HANDLER) 

END 


OPERATOR  D I S F LAY_WAYPO INT 
SPECIFICATION 


INPUT  WP  number 
WF_1 
WF_2 
WF  3 


INTEGER; 

POSITION; 

POSITION- 

POSITION; 


OUTPUT  WF_1 
WP_2 

WF__3 

WP  number 


END 


POSITION 

POSITION 

POSITION 

INTEGER; 


IMPLEMENTATION  ADA  DISPLAY  WAYPOINT 


{The  atomic  operator  DISPLAY_WAYPOINT  requires  visibility  to  datastreams 
WP_1,  WP_2,  WP_3  and  WP_NUMBER  in  DISPLAY  HANDLER) 


END 
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OFERATOR  DISPLAY  COURSE  AND  SPEED 


SPECIFICATION 

INPUT  Course 
Speed 

OUTPUT  Course 
Speed 


FLOAT; 

INTEGER; 

FLOAT; 

INTEGER; 


END 

IMPLEMENTATION  ADA  D ISPLAY_COURSE_AND_SPEED 

{The  atomic  operator  DISPLAY_COURSE_AND_SPEED  requires  visibility  to 
datastreams  COURSE  and  SPEED  in  DISPLAY  HANDLER) 


END 


OPERATOR  BEAF.ING_BUFFER 
SPECIFICATION 

INPUT  Bearing  :  FLOAT; 

OUTPUT  Bearing  :  FLOAT; 

END 

IMPLEMENTATION  ADA  BEARING_BUFFEP. 

(The  atomic  operator  BEAF,ING_BUFFER  requires  visibility  to  datastream 
BEARING  in  D ISPLAY_HANDLER ) 

END 


OPERATOR  DISFLAY_BEARING_AND_DISTANCE 
SPECIFICATION 


INPUT  Bearing 
Distance 
WF  number 


FLOAT; 
FLOAT ; 
INTEGER; 


OUTPUT  Bearing 
Distance 
WP  number 


FLOAT; 

FLOAT; 

INTEGER; 


END 


IMPLEMENTATION  ADA  D I SPLAY_BEARING_AND_D I STANCE 

(The  atomic  operator  D ISPLAY_BEARING_AND_DISTANCE  requires  visibility  to 
datastreams  BEARING,  DISTANCE  and  WF~ NUMBER  in  DISPLAY  HANDLER) 


END 
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OPERATOR  D I STANCE_B'JFFER 
SPECIFICATION 

INPUT  Distance  :  FLOAT; 

OUTPUT  Distance  :  FLOAT; 

END 

IMPLEMENTATION  ADA  D ISTANCE_BUFFER 

(The  atomic  operator  DISTANCE_BUFFER  requires  visibility  to  datastream 
DISTANCE  in  DISPLAY_HANDLER} 

END 
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APPENDIX  B.  ADA  SOURCE  CODE  LISTING 


—  UNIT_NAME  I  ins. a 

—  CSCI_NAME 

—  UNIT  DESCRIPTION 


--  UNIT_SPS_REFER£NCE 

—  UNIT_CALLING_SEQUENCE 

—  EXTEFNAL_UNITS_CALLED 

—  INPUTS 

—  OUTPUTS 

--  CREATED  I  23  January  1989 

--  AUTHOR  |  herbert  guenterberg 

--  DATE - AUTHOR - REVISION  *  PR  * - -TITLE 


--  This  is  the  main  program  for  the  ins-simulator.  Compilation  sequence: 

Te  nr.  s  .  a , 

Term_b.a, 

Data_sto.a, 

Mathutil .a, 

Navutil.a, 

Ins  .  a 

--  To  link  on  a  UNIX  based  system  with  a  VERDIX  compiler: 
a. Id  -o  ins  ins  -ltermcap  -lcurses 


with  TEXT_IO ; 
use  TEXT_IC; 
with  TERMINAL; 
use  TERMINAL; 
with  NAVUTIL; 
use  NAVUTIL; 
with  CALENDAF; 
use  CALENDAF; 

with  FLOATING  POINT  UTILITIES; 


proceauit  iNo  is 


package  FLOAT_UTIL  is  new  FLOATING_PCINT_UTILITIES (FLOAT) ; 
use  FLOAT_UTIL; 

package  INT_IO  is  new  INTEGEP_IO ( INTEGER) ; 
use  INT  10; 


initialization  of  variables 

IN  IT  IAL_POS  I TI  ON  :  POSITION  :*=  (0.0,  0.0); 
INITI AL_COURSE  :  FLOAT  :=  0.0; 
INITIAL_SPEED  :  INTEGER  :=  0; 
INITIAL_BEAP.ING  :  FLOAT  :=  0.0; 

IN ITIAL_DI STANCE  :  FLOAT  :=  0.0; 

INITIAL  WF  :  INTEGEP  :=  1; 
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-  task  declarations;  names  are  self explanatory  for  each  task 

task  CHECK_KEYBOARD  is 
entry  START; 
entry  STOP; 
entry  CONTINUE; 
end  CH£CK_KEYBOARP; 
task  COMPUTE_POS ITION  is 
entry  START; 
end  COMP UTE_POS ITION; 

task  COMPUTE_BEARING_DISTANCE  is 
entry  START; 

end  COMP UTE_BEARING_D I STANCE; 

task  DISPLAY_HANDLER  is 

entry  MAKE_CHOICE (CHOICE  :  in  CHARACTER); 
end  DISPLAY_HANDLER; 

-  task  bodies 

task  body  CHECK_KEYBOARD  is 

NEW_CHOICE  :  CHARACTER  ;=  '6'; 

GLD_CHOICE  :  CHAPACTEP.  :=  ’  6'  ; 

TASK_START  :  TIME; 

TASK._DONE  :  TIME; 
begin 

accept  START  dc 

DISPLAY  HANDLER. MAKE_CHOICE (NEW_CHOICE) ; 
accept  STOP; 
accept  CONTINUE; 

SPECIAL_IO; 
end  START; 
loop 

TASK_STAPT  :=  CLOCK; 
if  :;::y_FKESSED  then 
GET (NEW_CHOICE) ; 

if  NEW_CHOICE  >  '0'  and  NEW_CHOICE  <=  '9'  then 
if  NEW^CHOICE  >  '0'  and  NEW_CHOICE  <  '6'  then 
CLEAP_LINE (3,  7); 

NORMAL_IO; 
end  if; 

DISFLAY_HANDLER.MAKE_CHOICE (NEW_CHOICE) ; 
accept  STOF; 
accept  CONTINUE; 

if  N EW_C HO I C E  >  '0'  and  NEW_CHOICE  <  '6'  then 
CLEAF_LINE (3,  7) ; 

SPEC I AL_IO ; 
end  if; 
end  if; 
end  if; 

if  NEW_CHO ICE  <  '6'  then 

DISPLAY_HANDLER.MAKE_CHOICE (OLD__CHOICE) ; 

else 

DISFLAY_HANDLER . MAKE_CHOICE (NEW_CHCICE> ; 
end  if; 
accept  STOF; 
accept  CONTINUE; 
if  NEW_CHOICE  >  '5'  then 
OLD_CHOICE  :=  NEW_CHOICE; 
end  if; 

TASK_D0NE  :=  CLOCK; 

delay  1.0  -  (TASK_DONE  -  TASK_START) ; 
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end  loop; 

end  C HE CK_ KEYBOARD ; 

task  body  COMPUTE_POSITION  is 
ACTUAL_TIME  :  TIME; 

OLD_TIME  :  TIME; 

INTERVAL  :  DURATION  :=  0.0; 

PRESENT_POS ITION  :  POSITION; 

TEMP_COURSE  :  FLOAT; 

TEMP_SFEED  :  FLOAT; 

INT_SPEED  :  INTEGER; 

TASK_START  :  TIME; 

TASK_DONE  :  TIME; 
begin 

accept  START  do 

OLD_TIME  :=  CLOCK; 
end  START; 
loop 

TASK__START  :=  CLOCK; 

AC  TU  AL_T I ME  :=  CLOCK; 

INTERVAL  :=  ACTUAL_T IME  -  OLDJTIME; 

OLD_TIME  :=  ACTUAL_T IME ; 

WP_BUFFER (0) . RECALL (PRESENT_POS ITION) ; 

COURSE_BUFFER. RECALL (TEMP_COURSE )  ; 

SPEED_BUFFER . RECALL ( INT_SPEED) ; 
fEMF_SPEED  :=  FLOAT ( INT_SPEED) ; 

UPDATE_P03 ITION (INTERVAL,  PRESENl_POSI TION ,  TEMF_COURSE, 
TEMF_SPEED) ; 

WP_BUFFEF,  (0)  .STOPX  (PRESENT_POS ITION)  ; 

TASK__P  ONE  :=  CLOCK; 

delay  1.0  -  <TASK_DONE  -  TASK_STkP1); 
end  loop; 

end  COMPUTE_POSITION; 

task  body  COMPUTE_BEAR.ING_D I  STANCE  is 
PP.ESENT_FOS  ITION  :  FOSITION; 

TARGE  T_P  OS  I T I ON  :  FOSITION; 

TEMF_BEAFING  :  FLOAT; 

TEMP _D I STANCE  ;  FLOAT; 

WP_N0  :  WAIT  0 INT_RAN GE ; 

TASK_STAPT  :  TIME; 

TASP'_D  ONE  :  TIME; 
begin 

accept  START; 
looF 

TASK_STAPT  ;=  CLOCK; 

WP_NUt-IEEP_B,JFFER  .RECALL  (WF_NO)  ; 

WF_BUFFEF.  (0)  .  RECALL  (  PRESENT_POSITION )  ; 

WP_BUFFER (WF_NO) . RECALL ( TARGET_POS ITION ) ; 

BEAR, ING_DI STANCE  (PR£SENT_POS ITION,  TAR GET_POS ITION, 
TEMP_BEAPING,  TEMP _D I STANCE) ; 

BF.ARING_BUFFEF  .STORE  (TEMP_BEAP, ING)  ; 

D I STANCE_EUFFEP . STORE (TEMF_D I STANCE) ; 

TASK_DONE  ;=  CLOCK; 

delay  1.0  -  (TASK_DONE  -  TASK_START) ; 
end  loop; 

end  COMPUTE  BEARING  DI STANCE ; 
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task  body  PI SPLAY_HANDLER  is 
OLD_CHCI CE  :  CHARACTER  :=  '1'; 

NEW_CHOICE  :  CHARACTER  :=  '6'; 

procedure  ENTER_PRESENT_POSITION  is 
begin 

CHECK_KEYBOARD . STOP ; 

GOTOXY (DR  -  3,  Cl); 

PUT ("ENTERING  PRESENT  POSITION"); 
GET_POSITION (0) ; 

CHECK_K£ YBOARD . CONTINUE; 
end  ENTER_PRESENT_POSITION; 

procedure  ENTER_WAYPOINT  is 

WP_NO  :  INTEGER  :=  MAX_WAYPOINTS  +  1; 
begin 

CHECK_KEYBOARD . STOP ; 

GOTOXY (DR  -  3,  Cl); 

PUT ( "ENTERING  WAYPOINT  NO:"); 
while  WF_NO  >  MAX_WAYPOINT£  loop 
GOTOXY (PR,  Cl); 

FUT( "ENTER  A  WAYPOINT  NUMBER  :  ">; 

GET (WF_N0)  ; 
end  loop; 

GOTOXY (DR  -  3,  C2); 

PUT ( INT_TC_CHAF (WP_N0) ) ; 

GET_P0SIT1CN (WF_NC) ; 

CHECK_KEYBCARC . CONTINUE; 
end  ENTEF._WAYPQINT ; 

procedure  ENTEF_COURSE  is 
begin 

C  H  E  C  K_KE  YB  0 ARD . STOP ; 

GET_COURSE; 

CHECK_KEYBOARD . CONTINUE; 
end  ENTEF_COrJRSE; 

procedure  ENTEF_SFEED  is 
begin 

CHECK_KE YBOAFI1 .  STOP; 

GET_SFEEI ; 

C  HE  C  KE YB  0 APB . CONTINUE; 
end  ENTEF_SF  EED ; 

procedure  ENTEF_STEEF_TO_WAYPOINT  is 
WF_NC  ;  INTEGER  :=  MAX_WAY FOINTS  +  1; 
begin 

C  HE  C  K_KE  YBOARD . STOF ; 
while  WF_NO  >  MAX_WAYPOINTS  loop 
GOTOXY (DR,  Cl); 

PUT ( "ENTEF  THE  TARGET  WAYPOINT  NUMBER 
GET (WF_NO) ; 
end  loop ; 

WF_NUMBEF_BUFFEF..STOPB  (WF_NO)  ; 
CHECK_KEYBOAPr  .CONTINUE ; 
end  ENTEF  STEEP  TC  WAYPOINT; 
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procedure  DISFLAY_PRESENT_POSITION  is 
PRESENT_POSITION  :  POSITION; 
begin 

CHECK_K£ YBOARD . STOP ; 

CLEAF._LINE  (DR,  1); 

WP_BUFF£R(0) . RECALL (PRESENT_POSITION ) ; 
DISPLAY_POSITION (PR£SENT_POSITION) ; 
GOTOXY (DR,  C2  +  20); 

POT ( "PRESENT  POSITION”); 

CHECK_KE YBOARD .CONTINUE; 
end  DISPLAY_PRESENT_POSITION; 

procedure  DISPLAY_WAYPOINT  is 
WF_NO  :  INTEGER; 

WAYPOINT  :  POSITION; 
begin 

CHECK_KE YBOARD . STOP ; 

WP_NUMBER_BUFFER .RECALL (WP_NO) ; 
CLEAP_LINE (DR,  1); 

WP_BUFFER (WP_NO) . RECALL (WAYPOINT ) ; 
DISPLAY_POSITION (WAYPOINT) ; 

GOTOXY' (DP,  C2  +  20); 

PUT ("WAYPOINT  "); 

FUT ( INT_TO_CHAR ( WP_NO) ) ; 

CHECK_KE YBOARD  .CONTINUE; 
end  DISFLAY_WAYPOINT; 

procedure  DISPLAY'_COURSE_AND_SPEED  is 
T_COURSE  :  FLOAT; 

INT_SFEED  :  INTEGER; 

T_SPEED  :  FLOAT; 
beain 

COURSE_BUFFER. RECALL <T_COURSE) ; 

SF EEC_BUFFER. RECALL (INT_SPEED) ; 

T_SPE ED  ;=  FLOAT (INT_SPEED) ; 

CHECK_KE YBOARD . STOP  ; 

GOTOXY (DR,  Cl); 

PUT (FLOAT_TO_STRING (T_COURSE) ) ; 

GOTOXY (DR,  C2) ; 

PUT (FLOAT_TO_STRING (T_SPEED) ) ; 

CHECK_KE YBOARD .CONTINUE; 
end  DISFLAY_COURSE_AND_SPEED; 

procedure  D1 SPLAY_BEAP ING_AND_D I STANCE  is 
T_BEAP.ING  :  FLOAT; 

T_ri STANCE  :  FLOAT; 

WF_NC  :  INTEGER; 
begin 

CHECK_KE YBOARD . STOP ; 

BEAR I NG_BUFFER .RECALL (T_BEARING) ; 
DISTANCE_BUFFER. RECALL (T_DISTANCE) ; 
WP_NUMBEP_BUFFER. RECALL (WF_NO) ; 

GOTOXY (DR,  Cl); 

PUT (FLOAT_TO_STRING (T_BEARING) ) ; 

GOTOXY (DR,  C2  -  5); 

PUT (FLOAT_TO_STR 1NG ( T_D I  STANCE ) )  ; 

GOTOXY (DP.  C2  +  20) ; 

PUT ( INT_TO_CHAR (WP_NO) ) ; 

CHECE_KE YBOARD .CONTINUE ; 
end  DISPLAY  BEARING  AND  DISTANCE; 
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begin 

--display_handler 

loop 

accept  MAKE_CHO ICE (CHOICE  :  in  CHARACTER)  do 
NEW_CHOICE  :*=  CHOICE; 
end  MAK£_CHOICE; 

if  OLD_CHOICE  /=  NEW_CHOICE  then 
case  NEW_CHOICE  is 
when  '6'  |  ' 7'  «> 

PREP ARE_POSITION_D I SPLAY; 
when  ' 8'  -> 

PREPARE_COURSE_SPEED_DISPLAY; 
when  ' 9'  => 

PREP ARE_BEARING_DISTANCE_D I SPLAY; 
when  others  => 
null ; 
end  case; 

OLD_CHOICE  NEW_CHOICE; 
end  if; 

case  NEW_CHCICE  is 
when  ' 1 '  *> 

ENTER_PR£SENT_POSITION; 
when  ' 2 '  => 

ENTEP_WAYFOINT; 
when  ' 3 '  => 

ENTEP_COURSE; 
when  ' 4 '  => 

ENTER_SFEED; 
when  ' 5 1  => 

ENTER_STEEF._TC_WAYPOINT; 
when  ' 6 '  => 

DISPLAY_PRESENT_POSITION; 
when  ' 7 '  => 

D I S  F  LA Y_WA YP  0 1 NT ; 
when  ' 8 '  => 

D I SPLAY_COURSE_AND_SPEED ; 
when  ' 9'  => 

D I SP  LAY_BEAP.ING_ANC_D  I  STANCE  ; 
when  others  => 
null  ; 
end  case; 
end  loop; 

end  D I SP LAY_KANDLEP ; 
begin  --  MAIN 
--  initialize  data  buffers 

for  Wp_NC  in  WAYPC INT_RANGE  loop 

WP_BUFFEP.  (VfP_NO)  .STORE  I!:iTIAl_POS  ITION)  ; 

end  loop; 

COURSE_BUFFEP . STORE ( IN ITIAL_COURSE )  ; 

SFEED_BUFFER. STORE ( INITI AL_SPEED ) ; 

BEARING_BUFFEP  .  STORE  ( INITI  AL_BEAF.ING )  ; 

DISTANCE_BUFFER. STORE ( IN IT IAL_DI STANCE ) ; 

**F  NUMBER  BUFFEF  .STORE  (INITIAL  WF  )  ; 
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-  initialize  screen  and  get  initial  user  input 

PREP ARE_SCREEN ; 

GET_POSITION (0) ; 

GET_COURSE; 

GET_SPEED; 

SPECIAL  10; 


-  start  tasks 

COMPUTE_POSITION .START; 
COMPUTE_BEARING_DI STANCE .START ; 
CHECK_K£YB0ARD . START; 

nd  INS; 
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I  mathutil .  a 


—  ONI T_NAME 

—  CSCI_NAME 

—  UNIT  DESCRIPTION 


—  UNIT_SPS_REFER£NCE  I  none 

—  ONIT_CALLING_SEQUENCE 

—  EXTERNA1_UN ITS_CALLED  |  none 
--  INPUTS 

—  OUTPUTS 

—  CREATED  I  17  November  1988 

—  AUTHOR  I  herbert  guenterberg 

—  DATE - AUTHOR - REVISION  t  —  PR  * - TITLE - 

—  This  package  provides  functions  which  are  not  specific  to  this  application 

—  and  are  not  provided  by  the  standard  math  library.  The  names  of  the 

—  functions  and  procedures  and  their  purpose  are  self  explanatory.  They  are  in 

—  part  taken  from:  Grady  Booch;  Software  components  with  Ada. 


generic 

type  NUMBER  is  digits  <>; 

package  FLOATING_POINT_UTILITIES  is 
type  BAoE  is  range  2  . .  16; 

type  NUMBERS  is  array  (POSITIVE  range  <>)  of  NUMBER; 
function  INTEGER_PART  (THE_NUMBER  :  in  NUMBER)  return  INTEGER; 
function  REAL_PART  (THE_NUMBER  :  in  NUMBER)  return  NUMBER; 
function  FLOOR  (THE_NUMBER  :  in  NUMBER)  return  INTEGER; 
function  CEILING  (THE_NUMBER  :  in  NUMBER)  return  INTEGER; 
function  IS_POSITIVE  (THE_NUMBER  :  in  NUMBER)  return  BOOLEAN; 
function  IS_NEGATIVE  (THE_NUMBER  :  in  NUMBER)  return  BOOLEAN; 
function  INT_TO_CHAF.  ( INNUM  :  in  INTEGER)  return  CHARACTER; 
function  CHAR_TC_INT  (INNUM  :  in  CHARACTER)  return  INTEGER; 
end  FLOATING  POINT  UTILITIES; 


package  body  FLOATING_POINT_UTILITIES  is 

function  INTEGEF_PART  (THE_NUMBER  :  in  NUMBER)  return  INTEGER  is 
begin 

if  IS_NEGATIVE  ( THE_NUMBER )  then 
return  CEILING  (THE_NUMBER) ; 

else 

return  FLOOR  ( THE_NUMBEP. )  ; 
end  if; 

end  INTEGEF_P ART ; 

function  REA1_PAPT  (THE_NUMBER  :  in  NUMBER)  return  NUMBER  is 
begin 

return  abs  (THE_NUMBEF  -  NUMBER ( INTEGEP_P ART (THE_NUMBER ))) ; 
end  FEAL  PAPT; 
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function  FLOOR  (THE_NUMBER  :  in  NUMBER)  return  INTEGER  is 
RESULT  :  INTEGER  :=  INTEGER (THE_NUMBER) ; 
begin 

if  NUMBER (RESULT)  >  THE_NUMBER  then 
return  (RESULT  -  1); 
else 

return  RESULT; 
end  if; 
end  FLOOR; 

function  CEILING  (THE_NUMBER  :  in  NUMBER)  return  INTEGER  is 
RESULT  :  INTEGER  :=  INTEGER (THE_NUMBER) ; 
begin 

if  NUMBER (RESULT)  <  THE_NUMBER  then 
return  (RESULT  +  1); 

else 

return  RESULT; 
end  if; 
end  CEILING; 

function  IS_PCSITIVE  (THE_NUMBER  :  in  NUMBER)  return  BOOLEAN  is 
begin 

return  (THE_NUMBEP  >  0.0); 
end  ISJPCSITIVE; 

function  IS_NEGATIVE  (THE_NUMBER  :  in  NUMBER)  return  BOOLEAN  is 
begin 

return  ( THE_NUMBER  <  0.0); 
end  IS  NEGATIVE; 


function  INT_TO_CHAR  ( INNUM  : 

OUTNUM  :  CHARACTER  :=  'O'; 
begin 

case  INNUM  is 
when  0  => 

OUTNUM  : =  'O'; 
when  1  =  > 

OUTNUM  :=  '1'; 
when  2  =  > 

OUTNUM  : =  ' 2 ' ; 
when  3  =  > 

OUTNUM  :=  '3'; 
when  4  => 

OUTNUM  : =  '  4  '  ; 
when  5  => 

OUTNUM  : =  ’5'; 
when  6  => 

OUTNUM  : =  ' 6 ' ; 
when  7  => 

OUTNUM  : =  ' 7 ' ; 
when  0  => 

OUTNUM  :=  ' 8  '  ; 
when  9  => 

OUTNUM  :=  '9'; 
when  others  => 

OUTNUM  : =  ' 0 '  ; 
end  case; 
return  OUTNUM; 
end  INT  TO  CHAP.; 


in  INTEGER)  return  CHARACTER  is 
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function  CHAR  TC_INT  (INNUM  :  in  CHARACTER)  r»:urn  INTEGER  is 
OUTNUM  :  INTEGER  :=  0; 
begin 

case  INNUM  is 
when  ' 0'  => 

OUTNUM  :=  0; 
when  ' 1 '  => 

OUTNUM  :«  1; 
when  '2'  => 

OUTNUM  : =  2; 
when  ' 3 '  «> 

OUTNUM  :=  3; 
when  ' 4 '  => 

OUTNUM  :=  4; 
when  '5'  «=> 

OUTNUM  5; 
when  ' 6'  => 

OUTNUM  :=  6; 
when  ' 7 '  => 

OUTNUM  :=  7; 
when  ' 8 '  => 

OUTNUM  :=  8; 
when  ' 9'  => 

OUTNUM  :=  9; 
when  others  => 

OUTNUM  :=  0; 
end  case; 
return  OUTNUM; 
end  CHAF_TC_INT; 
end  FLOATING  POINT  UTILITIES; 
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—  UNTT_NAME  I  navutil.a 

--  CSCI_NAME 

—  UNIT  DESCRIPTION 


—  UNIT_SPS_R£FERENCE 

—  UNIT_CALLING_SEQUENCE 

—  EXTERNAL_UNITS_CAT,LED  I  text_io,  terminal,  f loating_point_utilitiea, 

data_storage 

--  INPUTS 

—  OUTPUTS 

--  CREATED  |  19  November  1988 

—  AUTHOR  |  herbert  guenterberg 

--  DATE - AUTHOR - REVISION  *  ~  PR  # - TITLE - 


—  This  package  provides  the  routines  needed  in  navigation  programs  in  general. 


with  DATA  STORAGE; 


package  NAVUTIL  is 

MAX_WA YF  C I NT  S  :  INTEGER  :=  3; 

subtype  WA  YP 0 1 NT_RAN GE  is  INTEGER  range  0  ..  MAX_WAYPOINTS ; 
type  POSITION  is 
record 

LATITUDE,  LONGITUDE  :  FLOAT  :=  0.0; 
end  record; 

subtype  LAT_STR  is  STRING  (1  ..  7); 

subtype  L0N_STR  is  STRING  (1  ..  8) ; 
subtype  SPEED_STR  is  STRING  (1  ..  3); 
subtype  COURSE_STR  is  STRING  (1  ..  5); 
subtype  OUT_STRING  is  STRING  (1  ..  5); 


function  FLOAT  TO  STRING (REAL  IN  :  in  FLOAT)  return  OUT  STRING; 


procedure 

procedure 

procedure 

procedure 

procedure 


GET_POSITION  (WP_NC  :  in  WAYPOINT_RANGE) ; 
GET_SPEED ; 

GET_COURSE ; 

DISFLAY_POSITION  (T_POS  :  in  POSIT'ON); 
BEAF.ING  DISTANCE  (POSI  :  in  POSITION;  POS2 


in  POSITION;  BEG  :  out 


FLOAT;  DIST  ;  out  FLOAT) ; 

procedure  UPDATE_POSITION  (INTERVAL  :  in  DURATION;  T_POS  :  in  out  POSITION; 
COURSE  :  in  FLOAT;  SPEED  :  in  FLOAT); 

package  POSITION_STORAGE  is  new  DATA_STORAGE (POSITION) ; 

package  FL0A7_ST0RAGE  is  new  DATA_STORAGE (FLOAT) ; 

package  INTEGEP_STORAGE  is  new  DATA_STORAGE (INTEGER); 
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WP_BUFFER 
COURSE_BUFFER 
SPEED_BUFFER 
BEARING_BUFFER 
D I STAN  CE_BUFFER 
WF  NUMBER  BUFFER 


array  (0  ..  MAX_WAYPOINTS ) 
FI/'AT_S TORAGE .  BUFFER; 

IN TEGER_STORAGE  .BUFFER; 

FLO AT_STORAGE .BUFFER; 
FLOAT_STORAGE .BUFFER ; 
INTEGER  STORAGE .BUFFER; 


of  POSITION  STORAGE. BUFFER; 


end  NAVUTIL; 


with  TEXT_IO; 
use  TEXT_IO; 
with  TERMINAL; 
use  TERMINAL; 
with  MATH; 
use  MATH; 

with  FLOATING_POINT_UTILITIES; 
with  DATA  STORAGE; 


package  body  NAVUTIL  is 

package  FLOATUTIL  is  new  FLOATING_POINT_UTILITIES (FLOAT) ; 
use  FLOATUTIL; 

function  DEG_TC_RAD  (DEG  :  in  FLOAT)  return  FLOAT  is 
begin 

return  DEG  *  PI  /  180.0; 
end  D  E  G_TC _RAD ; 

function  RAD_TO_DEG  (RAD  :  in  FLOAT)  return  FLOAT  is 
begin 

return  RAD  *  18C.0  /  PI; 
end  RAD_TO_DEG; 

function  FLOAT_TC_STRING (REAL_IN  :  in  FLOAT)  return  OUT_STRING  is 
INT  :  INTEGER  :=  INTEGER_PART (REAL_IN) ; 

DECIMAL  :  FLOAT  :=  REAL_PART (REAL_IN) ; 

T_STP.ING  :  OUT_STRING; 

begin 

T_STRING ( 1 )  :=  INT_TO_CHAR ( INT  /  100); 

INT  :=  INT  mod  100; 

T_STPING(2)  ;=  INT_T0_CHAP.  ( INT  /  10); 

T_STRING(3)  :=  INT_TC_CHAF.  ( INT  mod  10); 

T_STRING (4 )  :=  '  : 

T_STF.ING  ( 5  )  :=  INT_TC_CHAR  (INTEGER_FAF.T  (DECIMAL  *  10.0)); 

return  T_STP.ING; 
end  FLOAT  TO  STRING; 
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--  All  procedures  of  name  GET_***  receive  an  input  string  and  convert  it  to 
--  tht  appropriate  data  type 


procedure  GET_POSITION  (WF_NO  :  in  WAYPO INT_RANGE )  is 
T_LAT_S  :  LAT_STR; 

T_LOK_S  :  LON^STR; 

LAT_DEG,  LON_DEG  :  INTEGER; 

LAT_MIN,  LON_MIN  :  FLOAT; 

SUCC1.  SUCC2,  SUCC3  :  BOOLEAN  :=  FALSE; 

T_?OS  :  POSITION  :=  (0.0,  0.0); 

begin 

CLEAR_LINE (7,  5); 

GOTOXY (DR,  Cl); 

PUT ("LATITUDE  N0000.0"); 

GOTOXY (DR,  C2 ) ; 

PUT ( "LONGITUDE  W00000.0"); 
while  not  SUCC3  loop 
T_LAT_S  :=  "N0000.0"; 

GOTOXY  (DR,  Cl  +  11); 

PUT (T_LAT_S) ; 

GOTOXY (DR,  Cl  +  11); 

GET ( T_LAT_S ) ; 

if  T_LAT_S(6)  =  '.'  and  (T_LAT_S(1)  =  'N'  or  T_LAT_S(1)  =  'n'  or 
T_LAT_S(1)  =  'S'  or  T_LAT_S(1)  =  's')  then 
SUCC1  :=  TRUE; 
else 

SUCC1  :=  FALSE; 
end  if; 

LAT_D£G  :=  CHAR_TO_INT (T_LAT _S (2) )  *  10  +  CHAR_TO_INT ( T_LAT_S ( 3 ) ) ; 
LAT_MIN  :=  (FLOAT (CHAR_TO_INT ( T_LAT_S (4 ) ) )  *  10.0  +  FLOAT <CHAR_TC_INT < 
T_LAT_S ( 5 ) ) )  *  1.0  +  FLOAT (CHAR_TO_INT (T_LAT_S (7) ) )  *  0.1)  /  60.0; 

if  LAT_MIN  <1.0  then 

SUCC2  :=  SUCC1  and  TRUE; 
else 

SUCC2  :=  FALSE; 

end  i f ; 

if  (FLOAT (LA T_DEG)  -  LAT_M1N)  <=  90. C  then 
SUCC3  :=  SUCC2  and  TRUE; 
else 

SUCC3  :=  FALSE; 
end  if; 

if  T_LAT_S(1)  =  'S'  cr  T_LAT_S ( 1 )  =  's'  then 

T_P0S. LATITUDE  :=  DEG_TO_RAD (FLOAT (LAT_DEG)  +  LAT_MIN)  *  (-  1.0); 

else 

T_POS. LATITUDE  :=  DEG_TC_FAD (FLOAT (LAT_DEG)  +  LAT_MIN) ; 
end  if; 
end  loop; 

SUCC3  :=  FALSE; 
while  not  SUCC3  loop 
T_LON_S  :=  "WOOOOO.O"; 

GOTOXY (DR,  C2  +  10); 

PUT ( T_LON_S ) ; 

GOTOXY (DP,  C2  +  10); 

GET (T_LON_S) ; 

if  T_LON_S(7)  =  '.'  and  (T_LOH_S(l)  *=  'W'  or  T_LON_S  ( 1 )  =  'w'  or 
T_LON_S  (1!  =  ' f  cr  T_LON_S(l)  «  '  e'  )  then 

SUCC1  :=  TRUE; 
else 

SUTC1  :=  FALSE; 
end  if; 
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LON_DEG  :=  CHAR_TO_INT (T_LON_S (2 ) )  *  100  +  CHAR_TO_INT (T_LON_S <3 ) )  *  10  + 
CHAR_TO_INT (T_LON_S (4 ) ) ; 

LON_MIN  :=  (FLOAT (CHAR_TO_INT (T_LON_S ( 5) ) )  *  10.0  +  FLOAT < CHAR_TO_INT ( 
T_LON_S ( 6 ) ) )  *  1.0  +  FLOAT (CHAR_TO_INT (T_LON_S (8) ) )  *  0.1)  /  60.0; 
if  LON_MIN  <1.0  then 

SUCC2  :=  SUCC1  and  TRUE; 

else 

SUCC2  :=  FALSE; 
end  if; 

if  (FLOAT (LON_DEG)  +  LON_MIN)  <-  180.0  then 
SUCC3  :=  SUCC2  and  TRUE; 

else 

SUCC3  :=  FALSE; 
end  if; 

if  T_L0N_S ( 1 )  «  'E'  or  T_LON_S(l)  -  'e'  then 

T_POS. LONGITUDE  :=  DEG_TO_RAD (FLOAT (LON_DEG)  +  LON_MIN)  *  (-  1.0); 
else 

T_POS .LONGITUDE  :=  DEG_T0_RAD (FLOAT (L0N_DEG)  +  LON_MIN) ; 
end  if; 
end  loop; 

WP_BUFFEP.  (WP_NO)  .STORE  (T_POS)  ; 
end  GE T_P 0 S I T I ON 

procedure  GET_SPEED  is 

SUCC  :  BOOLEAN  :=  FALSE; 

SPEET_S  :  SPEED_STR  :=  "000"; 

SE  EED_I  :  INTEGER  :=  0; 

begin 

CLEAP._LINE  (DR,  3); 

GOTOXY (DR,  Cl); 

PUT ("SPEED  :"); 
while  net  SUCC  loop 
GCTOXY (DR,  Cl  +  8); 

PUT ( SF  EED_S )  ; 

GOTOXY (DR,  Cl  +  8); 

GET ( SPEED_S ) ; 

SPEED_I  :=  CHAF_TC_INT (SFEED_S (1) )  *  100  +  CHAR_TC_INT ( SPEED_S ' 2 ) )  »  10+ 

CHAF_TC_INT (SFEED_S (3) )  ; 
if  SFEED_I  >  1  and  S?EED_I  <  500  then 
SUCC  :=  TRUE; 
else 

SUCC  :=  Ffd.SE; 
end  if; 
end  loop; 

SFEED_EUFFER  .  STOF.E  (SFEED_I)  ; 
end  GET  SPEED; 
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p_ocedure  GET_COURSE  is 

SUCC1,  SVCC2  :  BOOLEAN  :=  FALSE; 

CO0RSE_S  :  COURSE_STR  :=  "000.0"; 

COURSE_F  :  FLOAT  :=  0.0; 

begin 

CLEAR_LINE (DR,  3); 

GOTOXY (DR,  Cl); 

POT ("COURSE  :"); 
while  not  SUCC2  loop 
GOTOXY (DR,  Cl  +  10); 

POT (COURSE_S ) ; 

GOTOXY (DR,  Cl  +  10); 

GET ( C0URSE_S ) ; 
if  COURSE_S ( 4 )  -  then 

SUCC1  :=  TRUE; 
else 

SUCC1  FALSE; 
end  if; 

COURSE_F  :=  FLOAT (CHAR_TO_INT (COURSE_S (1 ) )  «  100  + 

CHAR_TO_INT (COURSE_S (2 ) )  *  10  +  CHAR_TO_INT (COURSE_S (3) ) )  + 

FLOAT (CHAR_TO_INT(COORSE_S (5) ) )  *  0.1?  if  COORSE_F  >=  0.0  and  COURSE_F  < 

359.9  then 

SOCC2  :=  SUCC1  and  TRUE; 
else 

SUCC2  :=  FALSE; 
end  if; 
end  loop; 

COURSE_BUFFER. STORE (COURSE_F) ; 
end  GET  COURSE; 


--  All  procedures  of  name  DISPLAY_***  take  an  input  and  convert  it  to  a  string 
--  for  screen  output 


procedure  DISFLAY_POSITION  (T 
TEMFLAT 
TEMP LON 
T_LAT_S 
T_L°N_£ 

LAT_DEG,  LON_DEG 
LAT~MIN,  LON_MIN 
LAT_MIN_INT,  LON_MIN_INT 
LAT_MIN_REAL,  LON_M I N_RE  AL 
beqin 


POS  :  in  POSITION)  is 
'  FLOAT  :=  RAD_T0_DEG (T_P0S -LATITUDE) ; 
FLOAT  :=  RAD_TO_DEG (T_P0S .LONGITUDE)  , 
LAT_STR; 

LON_STR; 

INTEGER; 

FLOAT; 

INTEGER; 

FLOAT; 


T_LAT_S ( 6 ) 

T_L°N_S ( 7 ) 

if  IS_NEGATIVE (TEMFLAT)  then 
T_LAT_S ( 1 )  : =  ' S ' ; 

else 


T_LAT_S ( 1 )  ; «  '  N '  ; 

end  if; 

TEMPLAT  :=  abs  (TEMPLAT) ; 

LAT_DEG  :=  INTEGER_P ART (TEMPLAT) ; 

T_LAT_S ( 2 )  :=  INT_TO_CHAR (LAT_DEG  /  10); 

T_LAT_S(3)  ;=  INT_TO_CHAR ( LAT_DEG  mod  10); 

LAT_MIN  :=  P.EAL_P  ART  (TEMPLAT )  *  60.0; 

LAT_MIN_INT  :=  INTEGEP_PAP.T  (LAT_MIN)  ; 

LAT_MIN_REAL  :=  REAL_PART (LAT_MIN) ; 

T_LAT _S(4)  :=  INT_TO_CHAR (LAT_MIN_INT  /  10); 

T_LAT_S  (  5  )  :=  INT_TO_CHAR  (LAT__MIN_INT  mod  10); 

T_LAT_S  (  7 )  :=  INT_TO_CHAR  ( INTEGEP._PART  (LAT_MIN_REAL  *  10.0)); 

if  IS  NEGATI’.’E  (TEMP LON)  then 
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T_L°N_S ( 1 )  : =  '  E '  ; 

else 

T_L0N_S(1)  :=  'W'; 

end  if; 

TEMPLON  :«=  aba  (TEMPLON); 

LON_DEG  ;=  INTEGERJP ART (TEMPLON)  ; 

T_LON_S(2)  :=  INT_TO_CHAR (LON_DEG  /  100); 

LON_DEG  :«=  LON  DEG  mod  100; 

T_LON_S ( 3 )  INT_TO_CHAR(LON_DEG  /  10); 

T_LON_S(4)  :*=  INT_TO_CHAR  (LON_DEG  mod  10); 

LON_MIN  :=  REAL_P ART (TEMPLON)  *  60.0; 

LON_MIN_INT  :=  INTEGER_PART (LON_MIN) ; 

LON_MIN_R£AL  :=  R£AL_PART <LON_MIN) ; 

T_LON_s ( 5 )  INT_TO_CHAR (LON_MIN_INT  /  10); 

T_LON_S ( 6 )  INT_TO_CHAR(LON_MIN_INT  mod  10); 

t_LON_S ( 8 )  : =  INT_TO_CHAR ( INTEGER_PART (LON_MIN_REAL  *  10.0)); 

GOTOXY (DR,  Cl); 

PUT (T_LAT_S) ; 

GOTOXY (DR,  C2  -  5); 

PUT (T_LON_S) ; 
end  DISPLAY_POSITION; 

procedure  BEAF  IN  5_D  I  STANCE  (P0S1  :  in  POSITION;  POS2  :  in  POSITION;  BRC-  : 

FLOAT;  DIST  :  out  FLOAT)  is 


LON  1 

FLOAT 

=  POS1 .LONGITUDE 

LON  2 

FLOAT 

=  POS2 .LONGITUDE 

LAT1 

FLOAT 

=  POS1 .LATITUDE  ; 

LAT2 

FLOAT 

=  POS2 .LATITUDE; 

LON  DIFF 

FLOAT 

=  LON2  -  LON 1 ; 

AP.C_DIFF 

FLOAT 

-  0.0; 

D 

FLO  A-" 

--  0.0; 

B 

FLOAT 

II 

c 

o 

procedure  DISTANCE  (LAT1  :  in  FLOAT;  LAT2  :  in  FLOAT;  LON_DIFF  :  in  FLOAT; 
VIST  ;  out  FLOAT)  is 
D  :  FLOAT  :=  0.0; 
begin 

D  :=  SIN (LATH  *  SIN(LAT2)  +  CCS(LATl)  *  COS(LAT2)  *  COS (LON_DIFF) ; 
if  D  '=  0.0  then 

D  :=  -  AP.CTAtv  ( SQP.T  (1.0  -  D  *  D)  /  D)  *  lOeOO.O  /  PI; 
end  if; 

DIST  :  =  at-  s  ( D  )  ; 
end  DISTANCE; 
be  gin 

DISTANCE (LAT1 ,  LAT  2 ,  LON_D IFF ,  DIST)  ; 
if  LAT 1  =  LAT2  then 
if  LON  1  <  LON 2  then 
BEG  :=  270.0; 

else 

BRG  :=  90.0; 
end  if ; 
end  if; 

if  LON 1  =  LON 2  then 
if  LAT1  >  LAT2  then 
BRG  :=  180.0; 

else 

BRG  :=  000.0; 
end  if; 
else 

B  :=  SIN (LON_DIFF)  /  (COS(LATl)  *  SIN(LAT2)  /  COS(LAT2)  -  SIN(LATl)  * 
CCS (LON_DIFF) ) ; 

B  :=  APCTAN(E)  *  180.0  i  PI; 
end  if; 


out 
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e; 


if  LON  1  >  LON2  and  LAT1  >  LAT2  then 
BRG  :=  160.0  -  B; 
end  if; 

if  LON 1  >  LON2  and  LAT1  <  LAT2  then 
BRG  : =  0.0  -  B; 
end  if; 

if  LON 1  <  LON2  and  LAT1  >  LAT2  then 
BRG  :=  180.0  -  B; 
end  if; 

if  LON  1  <  LON 2  and  LAT1  <  LAT2  then 
BRG  :=  360.0  -  B; 
end  if; 

end  BEAR ING_D I STANCE; 

procedure  UPDATE_POSITION  (INTERVAL  :  in  DURATION;  T_POS 
COURSE  :  in  FLOAT;  SPEED  :  in  FLOAT)  is 


in  out  POSITION; 


T_COURSE 

LAT_INC 

LON_INC 

DISTANCE 

begin 


FLOAT 

FLOAT 

FLOAT 

FLOAT 


=  DEG_TO_RAD ((90.0 

=  0.0; 

=  0.0 
=  0.0 


COURSE) ) ; 


DISTANCE  :=  SPEED 
LAT_INC 
LON_INC 
LON^INC 
if  COURSE 


/  3600.0  *  FLOAT (INTERVAL)  ; 

DISTANCE  *  SIN (T_COURSE)  /  60.0  *  PI  /  180.0; 
=  DISTANCE  *  COS (T_COURSE)  /  60.0  *  PI  /  180.0; 
=  LON_INC  /  COS (T_POS .LATITUDE) ; 

0.0  or  COURSE  =  360.0  or  COURSE  =  180.0  then 


T^POS . LATITUDE  :=  T_POS . LATITUDE  +  LAT_INC; 
jlse 

if  COURSE  =  90.0  cr  COURSE  =  2T0.0  then 

T  PCS . LONGITUDE  :=  TJPOS . LONGITUDE  -  LON_INC; 
else 


T_F OS .LATITUDE  := 
T_POS. LONGITUDE 
en d  i f ; 
end  if; 

end  UPDATE  POSITION; 


T_P0S .LATITUDE  +  LAT_INC; 

=  T  POS .LONGITUDE  -  L0N_INC; 


NAWTIL; 
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I  TERM  S . A 


—  UNIT_NAME 

—  CSC I_NAME 

—  UNIT  DESCRIPTION  I  SUPPORT  TERMINAL  INTERFACE 


--  UNIT_SPS_REFER£NCE 

—  UNIT_CALLING_SEQUENCE 

—  EXTERNAL_UNITS_CALLED  I 

—  INPUTS 

—  OUTPUTS 

—  CREATED  I  17  November  1988 

--  AUTHOR  I  herbert  guenterberg,  PUBLIC  DOMAIN 

--  DATE - AUTHOR - REVISION  #  --  PR  # - TITLE 


--  This  package  supplies  the  atomic  functions  and  procedures  used  by  the  main 
--  program  to  modify  screen  output  to  fit  the  application 


package  TERMINAL  is 

DASH  LINE  :  constant  STRING  := 


--  column  and  row  definitions  for  screen  output 

Cl  :  INTEGER  :=  5; 

CZ  :  INTEGER  :=  •4  0; 

DR  ;  INTEGER  :=  7; 

--  UNIX  specific  procedures  needed  to  allow  monitoring  keyboard  interrupt 

procedure  N0RMAL_I0; 

procedure  SPECIAL^IO; 

--  clear  the  screen 

procedure  CLEAF._SCREEN; 

--  position  the  cursor  anywhere  on  the  screen 

procedure  GOTOXY (ROW,  COLUMN  :  in  INTEGER); 

--  takes  the  first  line  and  the  number  of  lines  to  be  cleared 

procedure  CLEAF_LINE (LINE,  NUMBER  :  in  INTEGER); 

--  monitors  keytoard  interrupt  has  to  be  used  in  conjunction  with  NORMAL_IO 
—  and  SPECIAL_iO 

function  KEY_P RESSED  return  BOOLEAN; 

--  prepare  the  screen  for  different  output  modes 

procedure  PREP ARE_PQS ITION_D ISPLAY ; 

procedure  PF.EP AF.E__COURSE_SFEED_D ISFLAY ; 

procedure  RPEF  Af.F_BEAR.ING_D  I  STANTE_D  ISFLAY  ; 

procedure  F PEF AF E_ SCREEN ; 
end  TEFMINAL; 
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I  term_b.a 

|  SUPPORT  TERMINAL  INTERFACE 


--  UNIT_SPS_REFERENCE 

—  UNIT_CALLING_SEQUENCE 

—  E)"'ERNAL_UNITS_CALLED  I  TEXT_IO,  ASCII,  CURSES,  IOCTL,  SYSTEM 

—  INPUTS 

—  OUTPUTS 

—  CREATED  |  17  November  1968 

—  AUTHOR  I  herbert  guenterberg  /  PUBLIC  DOMAIN 

--  DATE - AUTHOR - REVISION  #  —  PR  # - TITLE 


—  UNIT_NAME 
--  CSCI_NAME 

—  UNIT  DESCRIPTION 


—  This  package  body  is  the  only  part  of  the  program  that  contains  TERMINAL 

—  specific  cede 


with  TEXT_IO 
use  TEXT_I C ; 
with  CURSES; 
use  CURSES; 
with  IOCTL; 
use  IOCTL; 
with  SYSTEM; 
use  SYSTEM; 


package  body  TERMINAL  is 

package  INT_IO  is  new  TEXT_IO . INTEGER_IO ( INTEGER) ; 
use  INT_IO; 
use  ASCII; 

type  TERMINAL_TYPE  is  (SUN,  VT100)  ; 

TERM  :  TERMINAL_TYPE  :=  SUN; 

procedure  NORMAL_IO  is 
begin 

CURSES .ECHO; 

CUPSLS . NOCRMCDE; 
end  NORMAL_IO; 

procedure  SPECIAL_IO  is 
begin 

CURSES .NOECHC; 

CURSES . CRMODE; 
end  SF EC IAL_IO; 

procedure  CLEAR, _SCPEEN  is 
begin 

MEW_PAGE ; 
end  CLEAF  SCPEEN; 
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procedure  GOTOXY (ROW,  COLUMN  :  in  INTEGER)  is 
begin 

case  TERM  is 
when  SUN  => 

PUT (ESC  &  "[")  ; 

INT_IO .PUT (ROW,  1); 

PUT ( ' ;  '  )  ; 

INT_IO. PUT (COLUMN,  1); 

PUT ( ' f '  )  ; 
when  VT 100  => 

PUT (ESC  4  "(") ; 

INT_IO.PUT (ROW,  1); 

PUT (';'); 

INT_IO.FUT (COLUMN,  1); 

PUT ( ' f ' ) ; 
end  case; 
end  GOTOXY; 

procedure  CLEAR_LINE (LINE,  NUMBER  :  in  INTEGER)  is 
begin 

GCTOXY (LINE,  1); 
for  I  in  1  . .  NUMBER  loop 

for  J  in  1  . .  79  loop 
TEXT_I0 . PUT ( "  ”); 
end  loop; 

NEW_LINE; 
end  loop; 
end  CLEAR  LINE; 

function  KEY_FRESSED  return  BOOLEAN  is 
GO  :  INTEGER; 

INT_VAF  :  INTEGER  :=  0; 

A  :  SYSTEM. ADDRESS  :=  INT_VAR' ADDRESS ; 
begin 

GO  :=  IOCTL . IOCTL ( 0 ,  F IONREAD ,  A)  ; 
return  INT_VAR  >  0; 
end  KEY_FRESSEL ; 

procedure  F  REF  AF.E_F0  S I T I  ON_D  I  SPLAY  is 
begin 

CLEAP_LINE (DR,  3); 

GOTOXY' (5,  Cl); 

TEXT_IC  .  FUT  (  " - ")  ; 

GOTOXY (8,  C2  -  5); 

TEXT_I0  .  FUT  (  " - ")  ; 

GOTOXY (8,  C2  +  20); 

TEXT_1 0  .  PUT  (  " - ”)  ; 

GOTOXY (9,  Cl); 

TEXT_IO . FUT ( "  LAT"); 

GOTOXY (9,  C2  -  5); 

TEXT_IO . PUT ( "  LONG"); 

GOTOXY (9,  C2  +  20)  ; 

TEXT_IO . PUT i "  FOSITION" ) ; 
end  PREPAF,E_PCSITION  DISFLAY; 
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procedure  PREPARE_COURSE_SPEED_DISPLAY  is 
begin 

CLEAR  LINE (DR,  3); 


GOTOXY18,  Cl); 

TEXT_IO  . PUT  (  " - ")  ; 

GOTOXY'  ( 6  ,  C2  )  ; 

TEXT_IO .  PUT  (  " - ")  ; 

GOTOXY  ( 9 ,  Cl); 


TEXT_IO . POT ( "  COURSE"); 

GOTOXY ( 9 ,  C2 ) ; 

TEXT_IO . PUT ( "  SPEED"); 
end  PREP AR£_COURS£_SPEEP_D ISP LAY; 

procedure  PREPARE_BEARING_DISTANCE_DISPLAY  is 
begin 

CLEAR_LINE (DR,  3); 

GOTOXY  (8 ,  Cl); 

TEXT_IO ,  PUT  (  " - ")  ; 

GOTOXY (8,  C2  -  5); 

TEXT_IO .  PUT  ( " - ")  ; 

GOTOXY (8,  C2  +  20); 

TEXT_IO .  PUT  (  " - ")  ; 

GCTOXY ( 9 ,  Cl); 

TEXT_IO . PUT ( "  BRG" ) ; 

GOTOXY ( 9 ,  C2  -  5); 

TEXT_IO . PUT ( ”  DIST"); 

GOTOXY ( 9 ,  C2  +  20); 

TEXT_IO . PUT ( "  TO  WP"); 
end  PREF ARE_BEARING_DI STANCE_D I SPLAY ; 

procedure  PREPARE^ SCREEN  is 
begin 

INITSCR; 

CLEAR_SCREEN; 

GOTOXY <1,  27); 

TEXT_IO . PUT ( " I  NS  SIMULATOR"); 
GOTOXY (2,  1); 

TEXT_I0 . PUT (DASH_LINE)  ; 

GOTOXY (14,  1 ) ; 

TEXT_IC . PUT (DASH_LINE) ; 

GOTOXY (16,  Cl)  ; 

TEXT_IO. PUT ("ENTER  /  UPDATE”); 

GOTOXY  (16,  C2 )  ; 

TEXT  10. PUT ("DISPLAY"); 


GOTOXY'  ( 1 "  ,  Cl); 

TEXT_I0  .  PUT  (  " - ")  ; 

GOTOXY (17,  C2  )  ; 

TEXT  10  .  PUT  (  " - "); 


GOTOXY (19,  Cl); 

TEXT_IO . PUT ( " [ 1 ]  PRESENT  POSITION"); 
GOTOXY (20,  Cl); 

TEXT_IO . PUT ( " [ 2 ]  WAYPOINT"); 

GOTOXY (21,  Cl); 

TEXT_IO . PUT ( " [ 3 ]  COURSE"); 

GOTOXY' (22,  Cl); 

TEXT_IO . PUT ( " [ 4 ]  SPEED"); 

GOTOXY (23,  Cl); 

TEXT_IO . PUT ( " | 5]  STEER  TO  WAYTOINT" ) ; 
GOTOXY (19,  C2 )  ; 

TEXT_IO . PUT ( " [ 6 ]  PRESENT  POSITION"); 

GCTOXY (20,  C2 ) ; 

TEXT_I 0 . PUT ( " [7]  WAYPOINT") ; 

GOTOXY' (21,  C2  )  ; 
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TEXT  10  .  PUT  (  "  [  8  ]  COU'-SE  /  SPEED”); 
GOTOXY(22,  C2)  ; 

TEXT_IO . PUT ( " ( 9]  BEARING  /  DISTANCE” J ; 
end  PREFARE_SCR£EN; 
end  TERMINAL; 
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I  data  sto.ada 


—  UNIT_NAME 

—  CSC I_NAME 

—  UNIT  DESCRIPTION  data  structure  to  store  data  in  tasks 


--  UNIT_SPS_REFERENCE 

—  UNIT_CALLING_SEQUENCE 

—  EXTERNAL_UNITS  CALLED 
--  INPUTS 

—  OUTPUTS 

—  CREATED  I  15  January  1989 

—  AUTHOR  I  herbert  guenterberg 

—  DATE - AUTHOR - REVISION  t  —  PR  I - TITLE 


--  This  package  supplies  the  necessary  data  structure  to  store  data  in  a  way, 
--  that  allows  more  than  one  task  to  access  these  data,  without  the  risk  of 
--  accessing  invalid  data,  or  more  than  one  task  trying  to  modify  the  same 
--  data  at  the  same  time.  The  implementation  is  generic  to  allow  for  different 
—  data  types  to  be  stored. 

--  The  algorithm  was  taken  from:  David  A. Watt  and  others;  Ada  Language  and 
--  Met hodologi e ;  Prentice  Hall;  1987 


generic 

type  ITEM_TYP£  is  private; 

package  DATA_STOFAGE  is 

task  type  BUFFER  is 

entry  STORE ( ITEM  :  in  ITEM_TYFE); 
entry  RECALL (ITEM  :  out  ITEM_TYPE) ; 
end  BUFFER; 
end  DATA_STOPAGE  : 

package  body  DATA_STOPAGE  is 

task  body  BUFFER  is 
DATUM  :  ITEM_TYFE; 
begin 
loop 

select 

accept  STORE  'ITEM  :  in  ITEM_TYFE)  dc 
DATUM  : =  ITEM; 
end  STORE; 
cr 

accept  RECALL  (ITEM  :  out  ITEM_TYFE)  do 
ITEM  :=  DATUM; 
end  RECALL; 
end  select; 
end  loop; 
end  BUFFER; 
end  DATA  STORAGE; 
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